Too many requests

rate_limit.exceeded · HTTP 429

What it means

A rate limit is spent for this minute, or the API is already storing as many injections as it takes at once. Each API key may make 60 wait calls and 600 other calls per minute; adding an authenticator and asking for a code count as wait calls, since they too can wait. In the dashboard the same limits apply per workspace, and per signed-in user on organisation pages. Injecting a message also meets the workspace's inbound limit, which mail sent on port 25 shares: 300 messages a minute per workspace, each recipient counting as one. The API stores at most two of a workspace's injections at once, fewer when it is busy, and an injection that waits 10 seconds without a turn is refused. Asking for a sign-in code too often is also answered with this code, and so is asking for one while too many wrong codes entered for the address pause its codes, with the limit wrong_codes; entering a wrong code is answered with auth.code_invalid, or auth.code_expired once the code is void. A signed-in account gets 10 codes an hour to confirm it's you or add addresses (limit user), with 60 seconds between two to one address (cooldown); an address being added gets 5 codes an hour and 20 a day, whoever adds it (address); 20 wrong such codes in a row, or 100 in 30 days, by one user or for one address being added, pause them (wrong_codes); and past half of the platform's hourly code limit no code is sent to add an address (platform). Retry-After says when.

What to do

Wait the number of seconds in the Retry-After header, then retry. Use wait rather than polling for mail, give each CI system its own key, and send a workspace's injections at most two at a time. For a sign-in code, a code that confirms it's you or one that adds an address, Retry-After says when a new one can be sent.

Every error the API returns is a JSON problem (RFC 9457) whose code names it and whose type links to its page here. See the docs for how the API works.