# Rate limits and concurrency (https://portal.usestring.ai/docs/api-reference/rate-limits)



Requests are rate limited per organization. When you exceed the limit, requests return `429 Too Many Requests`. Free
organizations get 1 request per second and every paid plan gets 60, and a higher rate is available on request.

## Concurrency [#concurrency]

Every plan can have up to **10,000 fetches** and **5,000 browser sessions** in flight at once. You do not need to
reserve or buy parallel slots.

In-flight requests settle at roughly your request rate multiplied by your average response time. At 60 requests per
second with a 0.5 s average response, that is about 30 requests in flight; if responses average 2 s, about 120. Keep
the average *rate* under the limit below and the parallelism takes care of itself.

## Rate limit [#rate-limit]

| Plan                                 | Request rate |
| ------------------------------------ | -----------: |
| Free                                 |      1 / sec |
| Paid: Starter, Growth, Scale, Volume |     60 / sec |
| Enterprise                           |       Custom |

The rate is averaged over a rolling 60-second window, so a short spike above it is admitted as long as your average
over the window stays under the limit. Sustained traffic above the rate gets `429`s.

Until your organization subscribes to a plan or adds funds, it is on the Free rate. Subscribing raises it within about a
minute, with nothing to change in your integration.

Need more? Email [support@usestring.ai](mailto:support@usestring.ai) with your expected request volume. A raised limit is applied to your organization
and takes effect on your next request — there is nothing to change in your integration.

## 429 response [#429-response]

```json
{
  "error": "Rate limit exceeded",
  "message": "Reduce request volume to 60 requests per second on average.",
  "limitRequestsPerSecond": 60
}
```

The response includes an `X-RateLimit-Limit-Rps` header with your allowed average requests per second, and
`Retry-After: 1`. That header and `limitRequestsPerSecond` both report **your organization's** limit.

## Handling 429s [#handling-429s]

* Back off and retry with exponential backoff and jitter.
* Smooth bursts on the client side so your average stays under the limit.
* Cache results where you can to avoid re-fetching the same URL.
* Throttle on *rate*, not on parallelism. Lowering your worker count is an indirect way to slow the request rate and
  costs you latency; a rate limiter on the client is the direct fix.