Skip to main content
Every request carries an API key as a bearer token:
Send the key in the header, never in a query string. URLs end up in server logs, browser history and Referer headers — a key in a URL is a key you have to assume is public.

​
Key format

Keys are 256-bit random strings. We store only a SHA-256 hash, so a key is shown exactly once, at creation — if you lose it, revoke it and mint another. There is no “show again”.

​
Scopes

Grant the narrowest scope that does the job. Scopes are hierarchical: admin satisfies write, which satisfies read. If a key lacks the scope an endpoint needs, you get 403 INSUFFICIENT_SCOPE. The message names the scope required and never the scopes granted — a stolen read key shouldn’t double as a map of what else to try.
Use a separate key per integration. Rate limits are per key, so one noisy job can’t starve another, and you can revoke one without disturbing the rest.

​
Expiry and rotation

A key can be created with an expiry of 30, 90 or 365 days, or none. An expired key behaves exactly like a revoked one — 401 INVALID_TOKEN, no grace period. To rotate without downtime:
1

Create the replacement

Same scopes, new key.
2

Deploy it

Roll it out everywhere the old key was used.
3

Confirm the old key is idle

The dashboard shows Last used per key, updated within a minute or so.
4

Revoke the old key

Effective on its next request.
An organization can hold up to 20 active keys. That’s a blast-radius limit, not a licensing one: rotate rather than accumulate.

​
When a key leaks

Revoke it in Settings → API keys. Revocation takes effect on the next request — there is no cache to wait out. What a leaked key can and cannot do:
  • It is bound to one organization. It cannot read another organization’s data, and cannot be widened.
  • It carries only its own scopes. A read key cannot create or delete anything.
  • It cannot change billing, invite team members, alter branding, or read candidate workspace archives beyond the signed URLs the API already returns.
  • It can read candidate names, emails and hiring reports within your organization — treat a read key as personal data access, not merely metadata.

​
Brute force

Repeated failed authentication from one IP is throttled. Once tripped, responses stop distinguishing a wrong key from a valid one, so failures carry no information. Successful requests never count toward it, so a busy integration — including several behind one NAT — is unaffected.