Rate limits & retries - Workchats Developer Docs

Limits

Endpoint(s)	Limit
`POST /v1/messages`, per installation	5/s sustained, bursts of 20
`POST /v1/messages`, per destination (same user, group or channel)	1/s sustained, bursts of 5
`PATCH /v1/messages/{id}`, `DELETE /v1/messages/{id}`	60/min
`GET /v1/users`, `GET /v1/conversations`, `GET /v1/conversations/{conversation_id}/messages`	20/min
`GET /v1/users/{id}`, `GET /v1/users/lookup`	100/min
`GET /v1/auth/test`, `GET /v1/conversations/{id}`, `GET /v1/conversations/{conversation_id}/files/{id}`	100/min
`POST /oauth/token`, `POST /oauth/revoke`	20/min per App

These are published as minimums — treat them as the ceiling to design against, even though the actual enforcement can occasionally allow a bit more.

Going over

{ "ok": false, "error": { "code": "rate_limited", "message": "…" }, "request_id": "…" }

429 rate_limited comes with a Retry-After header, in seconds. Wait exactly that long, then retry — don’t guess your own backoff for this one, the header already tells you the right number.

Bursty sends

If you’re delivering a burst of related events (an import, a bulk import of leads, or similar), collapse them into fewer messages rather than sending one per item — a single summary message (“214 new leads from import Q4 list”) stays well under the per-second limits that many individual posts would hit.

Retrying failures

429 and 5xx are safe to retry — the request either never took effect or your Idempotency-Key makes a repeat harmless. 4xx other than 429 won’t succeed on retry without changing the request; fix the request instead.