Skip to main content
Two kinds of limit apply to the API and the MCP server. They are easy to confuse because both say “no” for a while; they are unrelated.

​
The request limit, per token

Each token may make a fixed number of requests per minute — 120 today, counted in a window that resets every minute. A request past that answers 429 rate_limited with a Retry-After header naming the seconds until the window resets, and the same number in the body as retry_after_seconds:
The counter is per token, not per workspace or per user: two tokens in the same workspace have two counters. It is also durable, so a refusal survives the application restarting; waiting is the only thing that clears it. The MCP server sits behind the same door, so a chatty assistant meets the same limit. A refused request is not “used”: it does not update the token’s last-used time.
Honour Retry-After rather than retrying on a fixed schedule. Most HTTP clients treat 429 as retryable and will wait the right time if you let them read the header.

​
Two more 429s

Separately, two abuse bounds answer 429 limit_reached with a sentence naming the bound that was hit. They are the same on every plan, and neither is something the plan sets:
  • 300 new links per day, per workspace. Counted the same way whether the link came from the console, the assistant or the API. The refusal carries no Retry-After header.
  • 10,000 conversions per hour, per token. The refusal carries a Retry-After header and retry_after_seconds in the body, like the request limit.
The MCP server returns the link bound’s sentence as a tool result; there is no conversions tool. Same status as the request limit, different code: branch on code, not on the status.

​
What is not a limit here

The product’s own chat assistant, inside the console, runs under bounds of its own so that a conversation cannot run away. Those bounds are the chat’s, not the API’s or the MCP server’s: nothing you build against either door is affected by them, and nothing here lets you change them.