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

# Rate limits and usage

> Daily request quotas, burst rate limits, and response headers that report remaining capacity

The Platform API applies two independent limits. Both are reported on every response through HTTP headers so you can monitor consumption without a separate status endpoint.

## Daily request quota

Each workspace has a daily cap on **successful** API requests (HTTP `2xx` responses). Failed requests do not count toward the quota.

| Property | Default                                                                          |
| -------- | -------------------------------------------------------------------------------- |
| Scope    | Workspace (all API keys in the workspace share one counter)                      |
| Limit    | 2,000 requests per UTC day                                                       |
| Reset    | Midnight UTC, based on a one-day rolling window tied to the last counted request |

When the daily quota is exhausted, the API returns `429 Too Many Requests` with body `{"error":"quota limit reached"}`.

Requests made by installed vibe apps on behalf of end users are exempt from the daily quota.

## Burst rate limit

Each authenticated user also has a short-term token-bucket limit that prevents request spikes.

| HTTP method       | Sustained rate        | Burst capacity |
| ----------------- | --------------------- | -------------- |
| `GET`             | 100 requests / second | 20 concurrent  |
| All other methods | 20 requests / second  | 5 concurrent   |

When the burst limit is hit, the API returns `429 Too Many Requests` with a structured error body (`code: rate_limit_exceeded`).

## Response headers

Every Platform API response includes headers for both limits. Values reflect state **after** the current request is processed (for successful quota-eligible requests, the daily counter includes the request you just made).

### Daily quota

| Header                       | Description                                                   |
| ---------------------------- | ------------------------------------------------------------- |
| `X-Assembly-Quota-Limit`     | Maximum successful requests allowed in the current UTC window |
| `X-Assembly-Quota-Remaining` | Successful requests remaining before the daily cap            |
| `X-Assembly-Quota-Reset`     | Unix timestamp (seconds) when the daily quota resets          |

### Burst rate limit

| Header                  | Description                                                                |
| ----------------------- | -------------------------------------------------------------------------- |
| `X-RateLimit-Limit`     | Maximum burst tokens for the authenticated user and HTTP method class      |
| `X-RateLimit-Remaining` | Tokens remaining in the bucket after this request                          |
| `Retry-After`           | Present on burst-limit `429` responses; seconds until a token is available |

### Example

```bash theme={null}
curl -i https://api.assembly.com/v1/me \
  -H "X-API-KEY: <your-api-key>"
```

```http theme={null}
HTTP/1.1 200 OK
X-Assembly-Quota-Limit: 2000
X-Assembly-Quota-Remaining: 1847
X-Assembly-Quota-Reset: 1719792000
X-RateLimit-Limit: 20
X-RateLimit-Remaining: 19
```

On a daily-quota `429`, `X-Assembly-Quota-Remaining` is `0`. On a burst-limit `429`, `X-RateLimit-Remaining` is `0` and `Retry-After` is included.

## Best practices

* Read quota headers on every response and back off before `Remaining` reaches zero.
* Treat `429` as retryable: honor `Retry-After` for burst limits and wait until `X-Assembly-Quota-Reset` for daily quota exhaustion.
* Spread bulk operations over time instead of firing large `Promise.all` fan-outs against the API.