Rate limits
The External API rate-limits at the edge (AWS WAF). Requests are bucketed by the combination of the Authorization bearer token and the x-e1-client-id header, so each credential has its own counter.
| Scope | Limit |
|---|---|
Per (bearer token, x-e1-client-id) bucket, across all /api/* paths | 100 requests per 5 minutes |
When a bucket’s counter exceeds the limit, further requests return 429 Too Many Requests until the window rolls over. Unauthenticated paths (/healthcheck, /swagger) are not rate-limited.
The 429 response does not include a Retry-After header — clients must back off using their own logic. See If you hit a throttle below.
Fair use
Even without enforced limits, please design integrations to be a good neighbour:
- Cache results. Supplier API responses are derived from data that changes on the order of hours, not seconds — see Data freshness. There’s no value in sub-minute polling.
- Coalesce callers. If multiple systems inside your organisation need the same data, fetch it once in a shared service rather than having each system poll independently.
- Back off on errors. Treat a run of
5xxresponses as a signal to slow down, not an invitation to retry faster. See Errors — Retry guidance.
If you hit a throttle
If you receive a 429 Too Many Requests:
- Back off exponentially (start at 1s, double each attempt, cap at ~60s) — no
Retry-Afterheader is provided. - Persistent throttling on otherwise-reasonable traffic is a signal to contact E1 support.
Volume expectations
If your integration anticipates sustained high volume (hundreds of requests per minute, or bulk onboarding events), let E1 know during onboarding so we can plan capacity.