Rate limits and concurrency

Current defaults are 180 requests/minute per IP, 60 per key, and 90 per account. The IP limit also applies to authenticated requests; keys on one account share the account rate limit. An account can run at most 5 data requests simultaneously, and each key also has its configured max_concurrent_requests limit. Bodies are limited to 256 KB and pages to 50 items.

The daily allowance caps successful REST data calls in a day; rate limits cap requests within a minute; concurrency caps requests still running. Verification uses no daily data call but is still rate limited. Lowering limit or creating another key does not bypass the account daily allowance. Serial requests reduce concurrency but do not increase the daily allowance.

API_DAILY_LIMIT_REACHED returns HTTP 429 after 10 REST data calls. Wait until 00:00 Asia/Shanghai; creating or rotating a key does not reset the account allowance.

For RATE_LIMITED, respect Retry-After and use backoff. Valid keys, scopes, rate limits, concurrency limits, and account restrictions remain in force.

Choose a recovery path using error.code, not HTTP 429 alone. RateLimit-Limit, RateLimit-Remaining, and RateLimit-Reset describe the short rate window. Reset is a Unix timestamp in seconds, not the daily reset time. Rate-window exhaustion supplies Retry-After in seconds; concurrency or daily-allowance 429 responses may omit it. Read daily_usage for daily usage and error.details.daily_usage for a daily-limit error.

Each successful REST data request counts once, including empty results and server cache hits. Reusing the same Idempotency-Key and parameters replays the original result without another daily call. Failed requests and 304 responses do not consume the daily allowance.

For RATE_LIMITED, respect Retry-After and use backoff. Valid keys, scopes, rate limits, concurrency limits, and account restrictions remain in force.

For RATE_LIMITED, wait for Retry-After first. If absent, reduce concurrency and use exponential backoff with a small random delay and a retry cap; for example, wait 1, 2, then 4 seconds before stopping and recording the request ID. Do not retry API_DAILY_LIMIT_REACHED every second: wait for the daily reset. Correct authentication, permissions, or parameters before retrying 401, 403, or invalid requests.

Keep the Idempotency-Key and parameters unchanged when retrying the same REST data operation. Generate a new key for a new logical operation; changing parameters while reusing the key causes IDEMPOTENCY_CONFLICT. Treat different pages as different operations. Retryable 5xx responses also require bounded backoff.

If two keys on one account each complete 5 data calls, the shared 10-call REST daily allowance is exhausted, even if no requests were made in the last minute. The website has a separate 10-search allowance. MCP uses neither daily allowance, but too many simultaneous MCP requests can still trigger RATE_LIMITED.