Rate Limits | Kwery

Rate limits are enforced per API key at per-minute and per-hour granularity. Exceeding either returns 429 Too Many Requests.

Per-tier limits

Plan	Requests/minute	Requests/hour
Free	15	600
Pro	50	3,000
Business	150	9,000
Enterprise	Custom	Custom

Response headers

Every authenticated response includes:

Header	Description
`X-Plan`	Your plan tier
`X-Credits-Used`	Credits charged for this request
`X-Credits-Remaining`	Credits remaining this billing period
`X-Rows-Returned`	Number of data rows
`X-Rows-Capped`	`true` if rows were capped to your tier max
`X-RateLimit-Limit`	Your rate limit ceiling
`X-RateLimit-Remaining`	Requests remaining in current window
`X-RateLimit-Reset`	When the rate limit window resets (Unix timestamp)
`X-Process-Time-Ms`	Server processing time in ms
`X-Request-ID`	Unique request identifier for debugging

Handling 429 responses

When you exceed your rate limit:

{
  "error": "rate_limit_exceeded",
  "message": "Rate limit exceeded. Retry after 12 seconds.",
  "retry_after": 12
}

The response also includes a Retry-After header. Use it (or retry_after in the body) to wait before retrying. Implement exponential backoff if you repeatedly hit the limit.

Max rows per response

Each plan caps the maximum rows a single request can return. If the result set is larger, the response is truncated and X-Rows-Capped is set to true.

Plan	Max rows
Free	100
Pro	1,000
Business	2,500
Enterprise	10,000

Use cursor-based pagination with meta.next_cursor to fetch the rest when X-Rows-Capped is true.

Best practices

Check X-RateLimit-Remaining and throttle when it’s low.
On 429, respect Retry-After or X-RateLimit-Reset before retrying.
Prefer fewer, larger requests (up to your row cap) instead of many small ones.
Call /v1/limits (0 credits) to check rate limit and credit status.
Log X-Request-ID for support and debugging.