title: Rate Limits and Timeouts
source_url: /developer-api/v1/rate-limiting
summary: API requests that take longer than 60 seconds will be terminated and return a 504 Gateway Timeout response. Most API requests complete well within this limit, but if you're working with large datasets or complex queries:

content:
API requests that take longer than 60 seconds will be terminated and return a 504 Gateway Timeout response. Most API requests complete well within this limit, but if you're working with large datasets or complex queries:

Use pagination to break large requests into smaller chunks.

Implement retry logic with exponential backoff for any 504 responses.

To ensure reliable and equitable access to our API, we enforce rate limiting. By default, API requests are limited as follows, applied per source IP address:

Limit: 200 requests per 10-second rolling window.

Reset Mechanism: The window operates on a rolling basis, meaning every new request resets the 10-second timer for that particular request.

When the rate limit is exceeded, the API responds with a 429 Too Many Requests status code. This indicates that further requests should be paused until the limit resets.

Implement backoff strategies: When receiving a 429 Too Many Requests response:
Implement exponential backoff (e.g., 1s, 2s, 4s) before retrying.
Avoid immediate retries, as this could worsen delays.

Implement exponential backoff (e.g., 1s, 2s, 4s) before retrying.

Avoid immediate retries, as this could worsen delays.

Optimize API calls: Consolidate requests wherever possible, such as using batch endpoints or minimizing redundant calls.

If you make 200 requests at 10:00:00, the limit will be reached, and subsequent requests will return a 429 response. If no further requests are made, the limit will reset by 10:00:10. However, if you continue making requests during the window, the rolling timer will extend accordingly.

If your application requires a higher limit, you can request an increase. To do so:

Analyze and document your expected API usage.

Submit a Developer API support ticket with your account details and usage requirements.

Providing clear information about your use case and anticipated volume will help expedite the review process.

Syncing data

Pagination is the mechanism for moving through a result set, but building a reliable sync pipeline also requires knowing which records to fetch and how often. This section covers how to do an initial bulk pull and keep your local data up to date efficiently.

The first time you sync a dataset, you will need to paginate through all records without any date filter. Expect this to be slow for large datasets — a business with years of transaction history may require hundreds of requests.

Recommendation: persist the data locally (in a database or cache) rather than fetching it on every app load. Once you have a local copy, you only need to fetch new or changed records on subsequent syncs.

After the initial seed, store a high-water mark (the timestamp of your last successful sync) and pass it to the appropriate date-filter parameter on subsequent requests. This avoids re-fetching records you already have.

Different endpoints expose different filtering capabilities:

GET /transactions

synced_after

Yes

Best delta sync support. Filters by sync time, not transaction time, so status changes and late-posted transactions are included automatically.

GET /bills

from_created_at

New records only

No updated-at filter. Periodic full re-pulls are needed to catch status changes such as payments and approvals.

GET /purchase-orders

Same as bills. Re-pulls are needed to pick up status updates.

Weekdays

Every 1–4 hours

Weekends

Every 12 hours

Adjust based on how time-sensitive your integration is. Real-time use cases should consider webhooks instead of polling.

With the default limit of 200 requests per 10-second window and a page size of 100 items, you can pull approximately 12,000 records per minute. For most integrations this is more than sufficient for incremental syncs, and even large initial seed pulls will complete within a few minutes.