The cap is per key
Not per person, and not per account. Every key has its own window, so a busy integration can never starve another one — and if one key misbehaves, revoking that key restores the rest immediately. The window rolls. It is not a clock that resets on the minute, so you cannot get double the allowance by firing at a minute boundary.What a refusal looks like
Retry-After header, in whole seconds, and repeated
in the body so you do not have to read headers to handle it. Honour it rather
than retrying immediately — a tight retry loop simply keeps the window full.
Staying under it
- Back off on
429and retry once the wait has passed. Most HTTP clients do this for you if you point them atRetry-After. - Use one key per place you call from. Two systems sharing a key share one window; two keys never collide.
- Batch your own work, not your requests. Ask for a week’s grid in one call rather than a day at a time.
- Do not poll for changes you could wait for. Polling every second burns the whole allowance on answers that did not change.
How assistant calls are counted
An assistant talking to your account spends the same window, and each message costs one slot — so a client that sends several at once spends several. One request may carry at most 20 messages. More than that is refused outright:400, not a 429, because waiting will not help — the request itself
has to be split. In practice you will never see it: current assistant clients
send one message per request anyway.
If you need more headroom
Before asking for a higher cap, check the three things that usually explain a429: a retry loop with no backoff, two systems sharing one key, and polling
where one call would do. If none of those is it, contact support and say what
the integration does and how often — the fix is often a different shape of call
rather than a bigger number.