> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.benchling.com/in-vivo/overview/rate-limiting/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.benchling.com/in-vivo/_mcp/server.

# Rate limiting

The Benchling In Vivo API enforces rate limits to ensure fair and reliable access for all users. Each tenant is allocated a fixed number of requests within a fixed time window; requests that exceed the limit are rejected until the window resets.

## Default Limits

| Scope                                         | Limit          | Window     |
| --------------------------------------------- | -------------- | ---------- |
| Per API key                                   | 300 requests   | 30 seconds |
| Per tenant (all API keys combined)            | 1,000 requests | 30 seconds |
| Token endpoint (`/api/public/v1/oauth/token`) | 60 requests    | 30 seconds |

## Response Headers

Every API response includes headers that report your current rate-limit status:

| Header                  | Description                                                                    |
| ----------------------- | ------------------------------------------------------------------------------ |
| `X-RateLimit-Limit`     | The maximum number of requests allowed for your API key in the current window. |
| `X-RateLimit-Remaining` | The number of requests remaining for your API key in the current window.       |
| `X-RateLimit-Reset`     | The number of seconds until the current window resets.                         |

> **Note**
>
> These headers reflect the per-API-key limit. A `429` response may still occur if the overall tenant-level limit is reached, even when the per-key remaining count is above zero.

## Exceeding the Limit

When you exceed a rate limit, the API responds with HTTP status `429 Too Many Requests`:

```json
{
  "error": "rate_limit_exceeded",
  "message": "Too many requests"
}
```

The `X-RateLimit-Reset` header on the response indicates how many seconds to wait before retrying.

## Best Practices

* **Space your requests.** Distribute API calls evenly rather than sending them in rapid bursts.
* **Monitor rate-limit headers.** Use `X-RateLimit-Remaining` and `X-RateLimit-Reset` to adapt your request rate before hitting the limit.
* **Back off on 429.** When you receive a `429` response, wait for the duration indicated by `X-RateLimit-Reset` before sending additional requests.