The Free plan is enforced by two sliding windows:
- A 60-second sustained window containing the plan’s full request budget.
- A 10-second burst window. Its quota is one sixth of the sustained budget, rounded down and capped at 1,000 requests.
ratelimit-remaining is 0 even though the sustained
window still has 20 requests available. Wait for burst capacity before sending
another request.
That key’s corresponding effective policy header is:
ratelimit-reset is a delta-seconds countdown, not the configured window size
or a Unix timestamp. During a burst rejection it describes the burst window;
during a sustained rejection it describes the sustained window. retry-after
uses the same recovery delay on a 429 response.
Rate Limit Responses
Rate limits by plan:
The Free per-second value is an average, not a separate one-second bucket.
Free burst traffic is governed by the 10-second quota.
The table gives the default plan policy.
The
ratelimit-policy and ratelimit-limit response headers are authoritative
for the key making the request. Private Cloud operators can configure or
disable the limiter for their deployment.
See Pricing for the full plan comparison, including monthly call quotas.
If you exceed your rate limit, you’ll receive a 429 response. Reduce the rate at which you request the API, for example by introducing a queue or reducing the number of concurrent requests.
The response body identifies which policy rejected the request and reports that
policy’s quota, window, and current reset countdown:
Burst rejection
Sustained rejection