Rate Limiting
The Invoicetronic API is rate-limited. When the rate limit is hit, clients receive a 429 Too Many Requests response until the limit window resets.
Global limits
The following limits are applied per-user to all authenticated requests:
| Period | Limit | Reset |
|---|---|---|
| Second | 100 requests | Every second |
| Minute | 2000 requests | Every minute |
| Day | 100000 requests | Daily |
Let's assume that 2000 requests hit the API within the one-minute window, subsequent requests occurring in that same minute will be blocked with 429. When the minute ends, the window resets, and the API will resume fulfilling requests.
Additional limit on polling endpoints
The read endpoints that are most commonly polled are protected by an additional per-user limit, based on a token bucket algorithm:
| Parameter | Value |
|---|---|
| Maximum burst | 200 instant requests |
| Sustained rate | 60 requests per minute |
It applies to all GET requests on:
/receive/(list and detail)/update/(list and detail)/send/(list and detail)/log/(list and detail)/webhookhistory/(list and detail)
The mechanism absorbs legitimate bursts without penalty, for example during sequential pagination of large result sets (up to 200 close-spaced requests in a few seconds), while capping the sustained long-term rate at 60 requests per minute. Once the burst is exhausted, subsequent requests receive 429 until the bucket refills.
This limit is additional to the global ones: a request must fit within both the global limits and the polling limit to be served.
Webhooks instead of polling
If you are frequently polling the /receive/ or /update/ endpoints to discover new events, consider using webhooks. Webhooks notify your system in real time when events occur, eliminating the need for polling entirely and drastically reducing the number of API calls.
Response Headers
Every API response includes the following rate limit headers:
| Header | Description |
|---|---|
RateLimit-Limit |
The most restrictive per-second permit limit (e.g. 100). |
RateLimit-Policy |
All active rate limit windows in the format limit;w=seconds. On polling endpoints it also includes the fragment 60;w=60;burst=200. |
Example values of RateLimit-Policy:
- Generic endpoint:
100;w=1, 2000;w=60, 100000;w=86400 - Polling endpoint:
100;w=1, 2000;w=60, 100000;w=86400, 60;w=60;burst=200
When a request is rejected with 429 Too Many Requests, the response also includes:
| Header | Description |
|---|---|
Retry-After |
Seconds to wait before retrying (e.g. 1). |
Tip
Your client should be prepared to handle 429 responses even if they are unlikely. When you receive a 429, read the Retry-After header to know exactly how long to wait before retrying. Don't let your client crash in a well-known, documented scenario like this; it would harm the end-user experience.