Rate limits
How many requests you can make, the rate-limit headers, and how to back off.
Two limits apply to every call, in 15-minute windows:
| Limit | Counted per | Applies to |
|---|---|---|
| 240 requests / 15 minutes | API key | Every authenticated call. |
| 300 requests / 15 minutes | Client IP address | Every call, including refused ones and GET /health. |
A single key on a single server is bounded by the per-key limit. Several keys sending from one IP address share that address's 300-request ceiling.
No endpoint has a tighter limit of its own, and every request counts as one.
Technology Providers' keys have limits of their own — per partner and per key — described in the Technology Providers book's Limits.
Headers#
Responses carry the IETF draft rate-limit headers. On an authenticated call they describe your key's window:
| Header | Example | Meaning |
|---|---|---|
RateLimit-Policy | 240;w=900 | The limit and its window in seconds. |
RateLimit-Limit | 240 | Requests allowed in the window. |
RateLimit-Remaining | 231 | Requests left in the current window. |
RateLimit-Reset | 412 | Seconds until the window resets. |
Retry-After | 412 | On a 429 only: seconds to wait before retrying. |
When you are limited#
A limited call answers 429. Its body has no code and no requestId:
{ "success": false, "message": "Too many Open Network requests. Please slow down." }{ "success": false, "message": "Too many requests, please try again later." }Wait the number of seconds in Retry-After, then retry. Watch RateLimit-Remaining to slow down before
you reach zero.
Staying within the limit#
- Sync only what changed. Send a catalogue write when an item changes, not a full re-send on a timer.
- Rely on webhooks for bookings and payments instead of polling.
- Spread batch jobs over the window instead of bursting.