To keep the platform stable for everyone, the Deliverect API limits incoming traffic. These limits apply to every endpoint on api.deliverect.com.
The limits are shared across all API consumers, not applied per client or per account. Heavy traffic from other consumers can therefore cause you to receive 429 responses even when your own request volume is low.
| Limit | Value |
|---|---|
| Request rate | 50 requests per second (sustained average) |
| Burst | Short spikes of up to 10,000 requests are tolerated before throttling |
| Concurrent requests | 500 requests in flight at the same time |
These values are enforced independently by each gateway instance, so the effective platform-wide capacity can be higher than the figures above. Do not rely on it. Treat the figures as the guaranteed minimum, and design your client to stay well below them.
When you are close to the request rate limit, some requests may be briefly delayed rather than rejected. Expect occasional slightly higher latency during bursts.
Rate-limited responses
When a limit is exceeded, the API responds with HTTP 429 Too Many Requests .
The response body is informational only. Don't parse it or rely on its exact text.
Example response when the request rate limit is exceeded:
HTTP/1.1 429 Too Many Requests
Retry-After: 1
Content-Type: text/plain; charset=utf-8
Too Many RequestsExample response when the concurrent requests limit is exceeded:
HTTP/1.1 429 Too Many Requests
Content-Type: text/plain; charset=utf-8
max connections reached: 500A Retry-After header may be included on request rate 429 responses. It is never included on concurrent requests 429 responses. Don't depend on it being present.
If the response includes a Retry-After header, wait at least that many seconds before you retry. The value is a minimum, not a recommended delay, so combine it with the backoff strategy below. If it doesn't, use the backoff strategy below.
Handling rate limits
Retry with exponential backoff. On a 429, wait (honouring Retry-After if present), then retry with increasing delays such as 2s, 4s, 8s, with some randomness (jitter) added, up to a maximum number of attempts.
To avoid hitting the concurrency limit, cap the number of requests your client has in flight at once, and smooth out bursts rather than sending them all at the same moment.