Limits and Quotas

This page details the built-in limits and quotas for ERPx APIs, ensuring reliable service and fair resource allocation for all tenants.

ERPx APIs have built-in limits to ensure reliable service for everyone. These limits prevent any single user or application from overwhelming the system, ensuring consistent performance for all customers.

The limits control two main things:

• How often you can make requests (rate limits)
• How much data you can transfer (quotas)

These limits are designed to:

• Prevent overloads caused by faulty scripts or runaway integrations
• Ensure fair resource allocation across tenants and applications
• Maintain performance during peak usage periods

Understanding these boundaries helps ensure your integration runs smoothly and without interruptions.    

Rate limit rules

General system limits

Tenant-level rate limits

Specialised API limits

Information Browser & Objects APIs

• Information Browser display: 99,999 rows maximum
• Information Browser aggregation: 750,000 rows maximum
• Information Browser Reports API: 750,000 rows maximum
• Objects API retrieval: 750,000 rows maximum
• Maximum Object API timeout: Streaming allows extended timeout if first bytes sent within 220 seconds

Reporting APIs

• System Report Quota: 480 system jobs per hour
• Concurrent report jobs: 15 simultaneous reports maximum

Amendment logging API

• Daily logging capacity: 20,000 events per day maximum
• Monitored tables: 10 tables maximum per logging server    

Rate limiting algorithm

We implement a sliding window rate limiting algorithm for flexible burst handling:

• Distributes request capacity evenly across time periods
• Allows natural traffic bursts while maintaining overall limits
• Prevents request starvation at window boundaries    

Best practices for high-volume use

Request optimisation strategies

Optimise record retrieval

Respect the 50,000 record limit per call:

GET /v1/objects/customers?limit=10000&offset=0

For larger datasets, implement pagination

GET /v1/objects/customers?limit=10000&offset=10000
GET /v1/objects/customers?limit=10000&offset=20000

Batch operations within size limits

Keep API call size under 5MB

POST /v1/employee/batch 
{
  "employee": [...], // Ensure total payload < 5MB
  "batch_size": 1000  // Process in manageable chunks
}

For large datasets, split into multiple batches

for (const batch of chunks(employee, 1000)) {
  await createEmployeeBatch(batch);
  await rateLimitDelay(); // Respect 500 req/min limit
}

Efficient filtering and field selection

Minimize data transfer with field selection

GET /v1/objects/customers?fields=id,name,email&limit=1000

Use targeted filtering to reduce response size

GET /v1/invoices?status=pending&date_from=2024-01-01&limit=1000

Rate limit management

Request distribution

• Spread your API calls evenly throughout the day rather than sending them all at once.
• Use a queue system for requests that aren’t time-sensitive.
• Consider using multiple authentication clients for different applications when appropriate.

Connection management

• Reuse connections when making multiple requests.
• Set reasonable timeout periods to prevent requests from hanging indefinitely.
• Use modern connection methods (HTTP/2) where available.    

Understanding error messages

What the response headers tell you

Every API response includes helpful information about your current usage:

• Retry-After: 60 (seconds, applicable for rate limit and quota)
• X-U4-QuotaType: OUTBOUND (applicable quota type)
• X-U4-RemainingLimit: 496 (number of calls left per minute)

Common limit-related response codes

• 413 Payload Too Large: Your request data is too big – break it into smaller pieces.
• 429 Too Many Requests: You’ve exceeded your rate limit – wait before trying again. Reason code “Quotas Exceeded” means you’ve exceeded your outbound quota.
• 503 Service Unavailable: The service is temporarily unavailable. A retry after a time delay often helps. Implement exponential backoff with jitter, using a maximum amount of retries.

Exponential backoff

• The delay between successive retries should increase exponentially (e.g., 1 second, 2 seconds, 4 seconds, 8 seconds). This prevents rapidly repeated requests from compounding the server’s overload issue.

Jitter

• A small, random amount of delay should be added to the exponential backoff time. This is known as jitter. It prevents many clients from synchronously retrying at the exact same time, which could create a “thundering herd” effect and instantly re-overload the server.

Maximum Retries

• Define a maximum number of attempts (e.g., 3–5 times).