Payloads, not requests
A batch of 500 costs 500. Limiting requests instead would let one client send 500-item batches as fast as it liked and call it one unit of load.Over the limit
Retry-After is in seconds and counts down to the end of the current window. The whole batch is refused — nothing is partially accepted.
The SDK does not retry. A refused batch is dropped, which costs a data point and nothing else.
What that limit is actually worth
10,000 payloads a minute is roughly 166 tool calls per second, sustained, from one server. Given the SDK flushes at 30 items or 5 seconds, hitting it takes real traffic rather than a misconfiguration. If you are near it, split across several keys on the same MCP — one per deployment — since the limit is per key.The window is per API instance
The counter is in memory. That is fine on a single instance and becomes N× the intended limit the moment the API scales horizontally, at which point it moves to shared storage. Stated rather than pre-solved, so that the behaviour you observe matches the behaviour that is documented.The monthly cap is a different thing
A rate limit protects the API from a burst. Your plan’s monthly allowance is a meter, and it answers differently:429 — the batch is dropped, nothing is retried, and your tool call is unaffected.
The verdict is cached for a minute, the same way an API key is, so a database round trip never happens inside somebody’s tool call. That is also why an upgrade takes up to a minute to take effect.
Reads are not limited
Metric reads, account routes and the MCP endpoint carry no rate limit today. They are authenticated per user and bounded by what a person or an agent can plausibly ask for.Other bounds
See Ingest for the per-field limits.