# Rate limits

> How identification is rate limited per organization, what a 429 looks like, and how the SDKs and your code should respond.

Last updated: 2026-09-17

Identify requests are rate limited per organization, across all of its keys and environments. Other endpoints are not rate limited.

## Limits

|  | Default |
| --- | --- |
| Sustained rate | 1,000 identify requests per second |
| Burst | Up to 2,000 requests at once, refilling at the sustained rate |

Development and staging traffic counts towards the same limit. If you need a higher limit, email [support@fingerly.io](mailto:support@fingerly.io).

## Headers

| Header | Meaning |
| --- | --- |
| `RateLimit-Limit` | Your organization's limit, per second. |
| `RateLimit-Remaining` | What remained when the request was admitted. |
| `Retry-After` | On `429`, seconds to wait. |

## When you exceed the limit

```json 429 Too Many Requests
{
  "error": {
    "code": "rate_limited",
    "message": "this organisation is sending faster than its rate limit allows",
    "status": 429
  },
  "request_id": "01a0a84c-0f11-7a3e-9c2d-4b5e6f708192"
}
```

- A refused request is not charged, and its `Idempotency-Key` is released so the retry is processed normally.
- Each refusal sends an [`identification.refused`](https://docs.fingerly.io/reference/webhooks/identification-refused) webhook with the reason `rate_limited`.
- The client SDKs retry `429` with jittered backoff.

> **Tip:** Identify at meaningful moments rather than on every page view, and use the framework SDKs, which share one identification per page.