API Rate Limits: Workspace vs Member

A rate limit that applies per workspace rather than per API key sounds simple until a team with several keys tries to reason about how much total throughput they actually have. The short answer: issuing more keys never raises the ceiling, because the limit belongs to the workspace, and every key in that workspace draws from the same shared allowance.

On top of the workspace ceiling, an owner can optionally give an individual member a smaller personal allowance, say 100 requests per minute out of a 500 workspace total. This is not an additional pool, it is a cap on how much of the shared pool that one member can draw at once, which stops one integration from starving every other user in the workspace.

A 429 response includes a Retry-After header with the exact number of seconds until the relevant window resets, and the error message itself states which ceiling was actually hit:

That message wording matters for debugging: a generic "rate limit exceeded" tells you nothing about which of the two ceilings, workspace-wide or personal, actually stopped the request. A response that names the specific allocation saves a support ticket.

A well-built rate-limited API returns quota state on every response, successful or not, rather than requiring a separate status call. That state includes an absolute reset_at timestamp rather than a relative "resets in X seconds," which matters because absolute timestamps do not drift if a scheduler checks them a few seconds late.