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

# Rate Limits for the VyomFlow API

> The VyomFlow API enforces per-user send-rate limits on message submission to protect shared provider budgets.

Sending a message (`POST /api/public/v1/chats/{chatId}/messages`) is rate-limited on a fixed time window. On the public API, the bucket is your API key's own id — not your account — so two keys belonging to the same user throttle independently, and one key can't exhaust the other's budget. When you exceed the limit, the API returns `429 RATE_LIMITED` immediately without consuming provider quota or credits.

## How it works

The limit is enforced before any provider call. A rate-limited request never reaches the LLM, never triggers a tool call, and never reserves or spends credits. This protects shared provider budgets from accidental or runaway client loops.

Every send response — success or `429` — carries these headers:

| Header                  | Meaning                                                 |
| ----------------------- | ------------------------------------------------------- |
| `X-RateLimit-Limit`     | Max sends allowed in the current window                 |
| `X-RateLimit-Remaining` | Sends left in the current window                        |
| `X-RateLimit-Reset`     | Unix epoch seconds when the window resets               |
| `Retry-After`           | Seconds to wait before retrying — only present on `429` |

If you are rate limited, the response body follows the standard [error envelope](/errors):

```json theme={null}
{
  "error": {
    "code": "RATE_LIMITED",
    "message": "You're sending too fast — please wait a moment and try again."
  }
}
```

## Upstream limits

The underlying LLM route (OpenRouter free tier) has its own daily and per-minute caps. These are separate from the application-level rate limit and may also produce errors. If you see a provider-level rejection after passing the application gate, treat it as an upstream quota issue and retry later.

## Best practices

* Implement exponential backoff with jitter when you receive a `429`.
* Surface the error to the user with a friendly message instead of silently retrying.
* Do not auto-retry immediately; the window is fixed and short retries are unlikely to succeed.

<Tip>
  A 429 response means your request was rejected before reaching the LLM. No credits were consumed.
</Tip>