Skip to main content

​
The short version

The authenticated Provider and Reseller APIs are not rate limited today. There is no request quota, no X-RateLimit-* header, and no 429 on any /provider/* or /reseller/* endpoint.The unauthenticated /public/shop/* write endpoints are limited, per IP.
We would rather tell you exactly what is enforced than publish limits we do not apply. This page will change when that changes — see Versioning for how we announce it.

​
What is limited

Both use a sliding one-minute window. Exceeding the window returns:
There is no Retry-After header on these responses. Retry after the window has moved — one minute is always sufficient. These endpoints back the consumer storefront at offergrid.io/shop, where a real shopper places one order. The limits exist to cap scripted submission volume, and are set well above anything legitimate browsing produces.

​
What is not limited

Every endpoint requiring an x-api-key header — the whole Provider and Reseller API — is currently unmetered. Your integration will not receive a 429 from them. That is a deliberate choice for the current stage, not an oversight, and not a guarantee. Do not build an integration that depends on it.

​
Build for limits anyway

Two habits cost nothing now and mean you need no changes when limits arrive: Handle 429 in your client. Treat it as retryable with backoff, honoring Retry-After when present. The error-handling helper on the Errors page already does both. Do not poll faster than your data changes. Order fulfillment moves on human timescales — a provider accepting an order, scheduling an installation. Polling GET /reseller/orders every 5–15 minutes is responsive enough for every workflow we have seen; once a day is plenty for orders in a terminal state. Tight polling loops are the usual reason an integration is the first to notice a new limit.
If you have a bulk or backfill job that would generate unusual sustained volume, tell us at support@offergrid.io first. We would rather plan for it with you than discover it in a graph.

​
When limits ship

When we introduce limits on the authenticated API we will, at minimum:
  • Announce them in the changelog before they take effect.
  • Return standard X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers on every response, so you can see your headroom before you hit a wall.
  • Include Retry-After on every 429.
  • Set the initial ceiling well above observed integration traffic.

​
Next steps

Errors

Every status code and a retry-safe client

API conventions

List responses, identifiers, timestamps, and money