Rate limits & fair use

Applies toEDITED MCPQuery APIJobs API

How much you can ask for, and how fast, differs by surface. MCP publishes no per-key limits today and runs on fair use. The REST APIs have concrete limits: the Query API caps requests per minute per endpoint, and the Jobs API limits concurrency, job size, and how long results stick around.

MCP

EDITED MCP

EDITED MCP currently enforces no published per-key rate limits. Usage is subject to fair use: the service is shared, and clients that hammer it with unnecessary traffic may be throttled or contacted.

If hard limits are introduced, they'll be announced in the changelog before they take effect.

Stay fast and friendly

The patterns that keep you inside fair use are the same ones that make your agent faster:

• Batch instead of looping. The market-data search tools accept a list of up to ten queries and run them concurrently — one round-trip instead of ten. See Concepts → Tools.
• Cache resolved identifiers. The slug/id values that searches return are stable — once your agent has resolved "Zara UK" to zara-uk, reuse it rather than searching again in the same session.
• Back off on 5xx. Retry transient failures with exponential backoff rather than tight loops — see Errors. Write clients to treat a 429 Too Many Requests the same way; it isn't sent today, but a client that already handles it won't break if limits arrive.

REST APIs

Query API Jobs API

The REST APIs have real limits, written into contracts and enforced to protect shared infrastructure. Exceeding a rate limit returns 429 Too Many Requests — back off and retry.

Query API — requests per minute

Query API

Limits are per endpoint, in requests per minute:

Endpoint	What it does	Requests / min
/option/*	Fetch a single option document	1000
/options/*	Filter and list option documents	100
/option_history/*	All tracked documents for one option, over time	10
/stats/*	Statistics and aggregations	10

A single response is also capped at 10,000 records; to pull more, page with the /page suffix (1,000 records per page). A very large /option_history request can time out with a 504 — split it into smaller date ranges. See the API reference for the endpoints and pagination.

Jobs API — concurrency, size, and polling

Jobs API

The Jobs API is built for bulk over-time extraction, so its limits are about job shape rather than request rate:

• One job at a time per account, by default. Further submissions are queued behind the running job; manage the order by cancelling and resuming.
• 500,000,000 results per job. A job estimated to exceed 500M documents is rejected at submit — split the work into smaller jobs by timeframe or filter.
• Poll at least once every 2 hours. A job running longer than two hours is cancelled for inactivity if it isn't polled (via Get Job or Get Job Result Files); a cancelled job can be resumed.

Jobs endpoints are rate-limited too, though the per-endpoint limits aren't individually published. The one builders hit most often is retrieving a large job's result files all at once — page through them with the next token at a measured pace rather than requesting everything at once, and treat a 429 as a signal to slow down rather than to retry straight away.

Retention

Jobs API

Job results don't stick around forever — download them promptly:

What	Retained for
Job details	60 days
Result files	30 days