Bavlio enforces per-key rate limits on requests authenticated with an API key. The limit varies by plan tier. Headers tell you the current state.Documentation Index
Fetch the complete documentation index at: https://docs.bavlio.com/llms.txt
Use this file to discover all available pages before exploring further.
Headers
| Header | Description |
|---|---|
X-RateLimit-Limit | Your current per-window limit (an integer). |
X-RateLimit-Reset | Unix epoch seconds at which the current window resets. |
Retry-After | Present only on 429 responses. Seconds to wait before retrying. |
There is no
X-RateLimit-Remaining header. Compute remaining requests yourself by tracking your own send count within the current window if you need an in-flight estimate. The headers above are sent on every response (where available).Caveats
- API-key auth only. Requests authenticated with a Supabase JWT (dashboard sessions) do not get rate-limit headers and follow a different limit.
- Redis-backed. Rate limiting depends on Redis. If Redis is unavailable, Bavlio fails open: requests proceed, but no headers are set. This is a deliberate tradeoff; reliability beats strict enforcement during infrastructure incidents.
- Per-key, not per-IP. Limits are scoped to your API key. Two keys on the same workspace each have their own bucket.
Example 429 response
Backoff pattern
HonorRetry-After exactly on 429. On 5xx, exponential backoff capped at a few attempts.
Python
See also
Errors & Idempotency
Full status code taxonomy, retry rules, and current idempotency state.
Quickstart
Minimal happy-path agent integration.