Rate limits per plan
The default
| Requests per minute | Requests per day | |
|---|---|---|
| New key default | 60 | 1,000 |
| Highest a key can be set to (by support) | 1,000 | 100,000 |
Rate limits aren't tied to your plan tier: the only plan requirement is Starter or above, since the API is a Starter+ feature. Changing a key's limits is not in the dashboard yet; support can raise them up to the ceiling above.
Limits are per API key, not per workspace. If you have two keys on the same workspace, each key gets its own independent budget: create separate keys per consumer or per tenant to give each one its own quota.
What counts as a "request"
Each request to /v1/query, /v1/query/stream or /v1/agent/escalate reserves one unit of the key's minute and day limits when it arrives:
- Successful requests keep the unit.
- Server errors (5xx) and an unknown
conversation_id(404) give the unit back. - Other rejections, such as 402, 403 or 429, can still use the unit today; refunding those is rolling out.
Message credits are separate: they are only used when an answer is produced.
OPTIONSpreflight requests don't count.- Webhook deliveries from AskVault to your endpoint don't count toward your quota; we eat that cost.
Response headers
AskVault does not send rate-limit headers today. Count your own requests if you need to stay under the cap.
429 Too Many Requests
When you exceed either limit, AskVault returns:
HTTP/1.1 429 Too Many RequestsContent-Type: application/json
{ "detail": "Per-minute rate limit exceeded (60/min). Try again shortly." }There is no Retry-After header. Read the detail message to see which limit you hit. The minute and day counters are independent: after the per-minute limit, back off for up to a minute; after the per-day limit, wait for the 24-hour window that starts with the first request after the last reset to free up.
Best practices
A few practices for production integrations:
Back off on 429. Most rate-limit issues come from clients that retry in tight loops. Use exponential backoff with jitter, starting at a few seconds.
Pace yourself. Keep your own count of requests per minute and per day, and slow down before you reach the cap.
Distribute work across keys. If you have a multi-tenant integration where each tenant should get its own quota, generate one API key per tenant. Each key has its own per-minute and per-day budget.
Use streaming for large user-facing requests. Streaming responses don't count differently from synchronous, but they let you display partial answers while the rest generates. UX wins.
Batch with care. AskVault doesn't have a batch endpoint. To process 1,000 queries quickly, send them with controlled concurrency that respects your key's per-minute limit (60 by default; support can raise it up to 1,000).
Adjusting per-key limits
Changing a key's limits is not available in the dashboard yet. Email [email protected] with the key's name and the limits you need, up to 1,000 requests a minute and 100,000 a day.
High-throughput integrations
If a single key at its highest limits (1,000/minute, 100,000/day) isn't enough, you have two options:
- Request a custom-limit key. Reach out to [email protected] with your expected peak request rate.
- Use multiple keys with smart routing. Each key gets its own independent budget; spreading load across 5 keys near their ceiling gives you up to 5x the throughput of a single key, both per-minute and per-day.
The multiple-keys approach is simpler if your traffic is well-distributed. A custom-limit key is better if you need one integration to hit predictable, very high throughput without managing multiple keys.
End users behind your backend
If your own end users call AskVault indirectly through your backend, pass each of them a unique session_id (up to 200 characters) so their conversations stay on separate threads:
{ "query": "...", "session_id": "your-app-user-id-42"}session_id separates conversation history only. Every request still counts against the calling API key's per-minute and per-day budget: there is no separate per-end-user limit. To stop one of your customers exhausting a shared budget, either cap them in your own backend or issue them their own API key, which gets its own independent budget.
Common pitfalls
429 the morning after a big batch. The daily window lasts 24 hours from the first request after the last reset, not from midnight, so a batch late yesterday can still count this morning.
Burstiness drops 429s under control. A heavy short burst (100 requests in 5 seconds) will hit the default 60/minute cap immediately. Stagger requests with a small delay, or ask support to raise the key's per-minute limit if sustained bursts are expected.
Counters drift between client and server. Your own count is an estimate. Leave headroom below the limit.
FAQ
Are rate limits per-IP or per-key?
Per-key. Two clients sharing the same key share the budget. Different keys get independent budgets, even from the same IP.
Do streaming requests count differently?
No. A streaming request that yields 100 tokens counts as 1 request, same as a synchronous request that yields the same answer.
Can I get a temporary increase for a launch?
Contact [email protected] ahead of the event; support can raise a key's limits up to 1,000 requests a minute and 100,000 a day.
What's the relationship between rate limits and the monthly message quota?
They are separate. Key limits cap how many requests a key can make; your monthly message credits cap how many answers your account can produce. Whichever runs out first stops requests, so a busy key can still use up a month's credits quickly.
Does AskVault rate-limit by IP?
Not for the REST API; limits are per key. The website widget does not use API keys; visitor abuse limits for it are part of chat guardrails, which are rolling out.