Skip to content
Try Free →

Rate limits per plan

Last updated: · 4 min read

The default

Requests per minuteRequests per day
New key default601,000
Self-serve ceiling1,000100,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. Once you have a key, raise or lower its limits independently (see Adjusting per-key limits below), up to the self-serve ceiling.

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"

Any HTTP call to /v1/* that returns a 2xx response. Specifically:

  • Successful POST /v1/query calls count.
  • Successful POST /v1/query/stream calls count.
  • 4xx and 5xx responses don't count against quota.
  • OPTIONS preflight requests don't count.
  • Webhook deliveries from AskVault to your endpoint don't count toward your quota; we eat that cost.

Response headers

Every response includes four rate-limit headers:

X-RateLimit-Limit-Minute: 60
X-RateLimit-Remaining-Minute: 47
X-RateLimit-Limit-Day: 1000
X-RateLimit-Remaining-Day: 845
X-RateLimit-Reset-Day: 1747353600

X-RateLimit-Reset-Day is a Unix timestamp (seconds) when the daily counter resets. Use it to schedule retries cleanly.

429 Too Many Requests

When you exceed either limit, AskVault returns:

HTTP/1.1 429 Too Many Requests
Retry-After: 23
Content-Type: application/json
{ "detail": "Per-minute rate limit exceeded. Retry after 23 seconds." }

The Retry-After header is in seconds. Sleep for that long, then retry. Don't retry immediately; you'll just get another 429.

The minute and day counters are independent. Hitting the per-minute cap means waiting up to 60 seconds. Hitting the per-day cap means waiting until midnight UTC.

Best practices

A few practices for production integrations:

Respect Retry-After. Most rate-limit issues in real apps come from clients that ignore Retry-After and retry in tight loops. The right behavior is back off, then retry. A simple exponential backoff that respects Retry-After works: wait max(retryAfter, base * 2^attempt) seconds.

Pre-compute backoff. Don't compute Retry-After after every 429. Track your remaining quota in advance using X-RateLimit-Remaining-Day. When it drops below your buffer threshold, slow down.

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, adjustable up to 1,000).

Adjusting per-key limits

Under Dashboard > API Keys > [key] > Edit, per key:

  • Lower the per-minute or per-day limit for a less-trusted consumer, or for cost containment.
  • Raise it for a high-throughput integration — up to 1,000 requests/minute and 100,000 requests/day.

This is self-serve at any Starter-or-above plan; you don't need to upgrade plans to raise a key's limit within that ceiling.

High-throughput integrations

If a single key's self-serve ceiling (1,000/minute, 100,000/day) isn't enough, you have two options:

  1. Request a custom-limit key. Reach out to sales@askvault.co with your expected peak request rate.
  2. 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.

Per-user rate limiting (separate from per-key)

If you're building an app where end users call AskVault indirectly through your backend, pass each user a unique user_id:

{
"workspace_id": "wt_xxx",
"message": "...",
"user_id": "your-app-user-id-42"
}

AskVault tracks per-user query rates. Configure caps under Settings > Rate Limits > Per-User. Useful for preventing one customer from exhausting your shared quota. Growth+

Common pitfalls

429 on the first request of the day. Per-day counters reset at midnight UTC, not in your local timezone. If you batched yesterday and ran into the cap, the first request after midnight UTC works again.

Retry-After: 0. Carrier proxies sometimes round this. Treat Retry-After: 0 as "wait at least 1 second before retrying".

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 inter-request delay, or raise the key's per-minute limit if sustained bursts are expected.

Counters drift between client and server. Don't trust your local counter; trust the response headers. Server time is authoritative.

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?

Each key can already self-serve up to 1,000 requests/minute and 100,000/day from the dashboard. If that's not enough, contact support@askvault.co at least 48 hours before the event and we can issue a custom-limit key.

What's the relationship between rate limits and the monthly message quota?

Daily limits enforce a moving cap on top of the monthly cap. You can't burn through your full monthly allowance in one day; the per-day cap holds you back. Useful for both cost and abuse prevention.

Does AskVault rate-limit by IP?

Not separately, no. Per-key only. If an attacker tries credential-stuffing your widget, the per-key cap takes effect.

Was this page helpful?