Rate limits
Two limits apply to every surface: per API key, and per account across all of your keys.
Every surface enforces two limits — one per API key, one per account across every key you hold. The account limit is checked first, since key issuance is unbounded up to your active-key cap and would otherwise let more keys buy more throughput.
Every rate-limited surface — the per-account cap is checked first; it is twice the per-key cap, so it is the one you hit once two or more keys share an account
| Surface | Per key | Per account |
|---|---|---|
Create a candidate (POST /candidates) | 100/hour | 200/hour |
Start a candidate (POST …/start) | 10/hour | 20/hour |
Reads (GET endpoints) | 300/hour | 600/hour |
List candidates (GET /candidates) | 120/hour | 240/hour |
Writes (PATCH/POST other than create and start) | 100/hour | 200/hour |
Compliance pack (GET …/pack) | 10/hour | 20/hour |
Settings write (PATCH /settings/assistant, PATCH /settings/quiet-hours) | 20/hour | 40/hour |
Every window is a fixed one hour, not a rolling average.
Exceeding either limit returns 429 Too many requests — please try again shortly. with a Retry-After header — wait at least that long before retrying.
A poll every 15–30 minutes per candidate (the Quickstart’s own cadence) stays comfortably under every read limit at any realistic roster size; a tighter poll loop on a large roster is the most common way to hit one.
These caps are sized for a synchronous integration that mirrors its own hiring pipeline. Planning a one-off backfill larger than the create limit? Contact support first rather than spreading it across keys.