API usage quota
Your API key has a usage quota that limits the number of requests you can make within a time period. This page explains how the quota system works.
How it works
Your quota operates on a rolling window basis:
- First request starts the window — When you make your first API request, your quota window begins.
- Window lasts for the plan period — The window remains active for the duration of your plan (24 hours for daily plans, 30 days for monthly plans).
- Quota resets after the window expires — Your next request after the time period has elapsed will start a fresh window.
Example: If you have a daily plan and make your first request at 3:00 PM on Monday, your quota will reset after 3:00 PM on Tuesday. Your next request after that time will start a fresh 24-hour window.
Plan types
| Plan type | Quota window | Notes |
|---|---|---|
| Daily | 24 hours | Legacy plans. Window resets 24 hours after your first request. |
| Monthly | 30 days | Current plans. Window resets 30 days after your first request. |
We previously offered daily plans but have since switched to monthly due to popular request. Monthly plans are better for e.g. handling traffic spikes, as one doesn't need to worry about hitting the daily limit, and have more time to upgrade if necessary.
Rate limit headers
Every API response includes headers that help you track your quota usage:
| Header | Description |
|---|---|
X-RateLimit-Limit |
Your total quota for the current window (e.g., 1000) |
X-RateLimit-Remaining |
Requests remaining in the current window (e.g., 750) |
X-RateLimit-Reset |
Unix timestamp when the current window expires and quota resets |
When quota is exceeded
If you exceed your quota, the API will return:
- HTTP 429 Too Many Requests status code
- The
X-RateLimit-Resetheader indicating when you can resume
You can also enable email notifications to receive an alert when your usage reaches a certain threshold (70%, 80%, or 90%). Configure this in your API key settings.
Rate limit
In addition to your plan's usage quota, we enforce a rate limit of 1,000 requests per second to maintain service quality and protect against abuse.
This limit is well above typical usage. If you're making high-volume requests, ensure your application reuses HTTP connections (connection pooling) rather than opening new connections for each request. Excessive concurrent connections may be flagged as a denial-of-service attack by our infrastructure.
Connection pooling by programming language
- PHP: Historically unsupported, rare workarounds exist. PHP 8.5 introduces
curl_share_init_persistent()which enables connection reuse across requests natively. - Go: Implements connection pooling natively using the default
http.Transport, assuming you fully read and close the response body. - Node.js: Uses connection pooling via
http.Agentby default since Node.js 19. Earlier versions require settingkeepAlive: true.