Using your key
Send the key in theX-Api-Key header on every request. The SDKs do this for you
once you construct the client:
Scopes
Keys carry scopes that gate what they can do. Read endpoints need no scope; write endpoints require the matching scope:| Scope | Grants |
|---|---|
employees:write | Create employees (POST /v1/employees) |
payroll:write | Create payroll runs (POST /v1/payroll/runs) |
leave:read | Read leave types, requests, and balances |
leave:write | Create/approve/reject/cancel leave, manage types & allocations |
advances:read | Read salary advances |
advances:write | Request/approve/reject salary advances |
performance:read | Read objectives, appraisals, and promotions |
performance:write | Manage objectives, appraisals, and promotions |
* | All scopes |
403 with code
INSUFFICIENT_SCOPE.
The add-on scopes (
leave:*, advances:*) also require the company to have
that add-on enabled. If it isn’t, those endpoints return 403
MODULE_NOT_ENABLED regardless of the key’s scopes — a company admin
enables it in Settings → Modules.Rotating a key
Rotate from the dashboard (orPOST /api-keys/{id}/rotate) to revoke the old
secret and mint a new one with the same name and scopes — so you can roll a
credential without reconfiguring the integration. The old secret stops working
immediately.
Keeping keys safe
- Never embed a key in client-side code or commit it to source control. Keys
begin with
kua_so secret scanners can spot leaks. - Use a separate key per integration so you can revoke one without affecting the others.
- Revoke unused keys from the dashboard.