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

# Errors and rate limits

> Handle Fluent API failures and throttling consistently.

## Errors

Non-2xx responses generally contain:

```json theme={null}
{
  "detail": "Agent not found",
  "status": 404
}
```

Common statuses are:

| Status | Meaning                                                            |
| ------ | ------------------------------------------------------------------ |
| `400`  | Invalid parameters or request body                                 |
| `401`  | Missing, invalid, expired, or unsupported credential               |
| `403`  | The credential is valid but lacks access or a required OAuth scope |
| `404`  | The resource does not exist or is not visible to the caller        |
| `409`  | The resource's current state conflicts with the operation          |
| `429`  | A rate limit was exceeded                                          |
| `500`  | Fluent or an upstream service failed unexpectedly                  |

Do not retry most `4xx` responses without changing the request. Retry transient `429` and `5xx` responses with exponential backoff and jitter.

## Rate limits

Authenticated API traffic is limited to 100 requests per 60 seconds per credential. Some expensive operations have tighter limits:

| Operation           | Additional limit                     |
| ------------------- | ------------------------------------ |
| Create an agent run | 30 requests per 60 seconds per agent |
| Read table records  | 5 requests per 60 seconds per user   |

### Rate limit headers

Every API response — not only a `429` — carries the current state of the tightest limit the request passed through, so a client can pace itself instead of waiting to be rejected:

| Header                | Meaning                                        |
| --------------------- | ---------------------------------------------- |
| `RateLimit-Limit`     | Requests allowed in the current window         |
| `RateLimit-Remaining` | Requests still available in the current window |
| `RateLimit-Reset`     | Seconds until the window resets                |

A `429` adds `Retry-After` (also in seconds) and, for backwards compatibility, the older `x-ratelimit-limit`, `x-ratelimit-remaining`, and `x-ratelimit-reset` headers — note that `x-ratelimit-reset` is a Unix timestamp in seconds, while `RateLimit-Reset` is a delta.

Treat `Retry-After` as authoritative on a `429`: wait that many seconds, then retry with backoff and jitter.

<Tip>
  Poll an active run about once per second, stop as soon as it reaches a
  terminal state, and prefer webhooks when you need ongoing lifecycle updates.
</Tip>