> ## Documentation Index
> Fetch the complete documentation index at: https://offergrid.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Rate limits

> What is rate limited on the Offergrid API today, and what to build for

## The short version

<Note>
  **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.
</Note>

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](/docs/api-reference/versioning) for how we announce it.

## What is limited

| Endpoint                                                                                    | Limit                | Scope         |
| ------------------------------------------------------------------------------------------- | -------------------- | ------------- |
| [`POST /public/shop/clicks`](/docs/public-api-reference/public/record-an-outbound-shop-click)    | 30 requests / minute | Per client IP |
| [`POST /public/shop/orders`](/docs/public-api-reference/public/place-a-checkout-mode-shop-order) | 10 requests / minute | Per client IP |

Both use a sliding one-minute window. Exceeding the window returns:

```json theme={null}
{
  "statusCode": 429,
  "message": "Too many requests"
}
```

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](/docs/api-reference/errors#handling-errors)
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`](/docs/reseller-api-reference/reseller-orders/list-your-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.

<Tip>
  If you have a bulk or backfill job that would generate unusual sustained
  volume, tell us at [support@offergrid.io](mailto:support@offergrid.io) first.
  We would rather plan for it with you than discover it in a graph.
</Tip>

## When limits ship

When we introduce limits on the authenticated API we will, at minimum:

* Announce them in the [changelog](/docs/api-reference/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

<CardGroup cols={2}>
  <Card title="Errors" icon="triangle-exclamation" href="/docs/api-reference/errors">
    Every status code and a retry-safe client
  </Card>

  <Card title="API conventions" icon="list-check" href="/docs/api-reference/conventions">
    List responses, identifiers, timestamps, and money
  </Card>
</CardGroup>