Rate limits

600 requests a minute, counted per token.

The number

600 requests in any 60 second window. Over it, the API answers 429.

The count is keyed on the token, so two tokens have separate budgets and your CI job does not spend the allowance of everything else behind the same egress address. Requests without a token are counted by IP instead.

The counter lives in the memory of the process that served the request, so behind more than one API instance you may get more than 600 before seeing a 429. Design against 600 and treat anything above it as headroom you did not plan for.

Handling a 429

Back off and retry with exponential backoff and jitter, up to a cap. There is no Retry-After header, so choose your own first delay; a second is plenty.

Staying underneath it

Two habits keep most integrations far below the limit.

Ask for more per request rather than making more requests. GET /api/tickets returns up to 500 in one call and takes the same filters the app’s saved views use, so one narrow request beats fifty lookups by id.

Read what changed rather than re-reading everything. GET /api/activity/feed returns the workspace’s recent changes in one request, so a job on a timer can fetch only the objects that moved. For push instead of poll, an admin can register an endpoint under Settings → Webhooks in the app.

Where the limits are tighter

Sign-in, password reset and the public intake form carry their own, much lower limits. None of them accepts a token, so nothing in the reference is affected.