Authentication
Server-side API calls use API keys. Create and revoke them at API keys.
API key management
Create a key, then use it from your backend
Open API keys and create a named key
Create one key per service or environment so it can be identified and revoked independently.
Copy a server-side example
Use the cURL, JavaScript, or Python request example and keep the key out of browser code.
Send the key in either header — both are accepted on every endpoint:
Authorization: Bearer YOUR_API_KEY
x-api-key: YOUR_API_KEY
x-api-key is what the Zapier app sends, and it's the form used throughout the Integration API examples. Pick whichever suits your HTTP client.
Organization scoping
A key is scoped to the authenticated user and to the organizations that user belongs to.
Keys are also bound to the workspace they were created in, so most requests need no organization parameter. On the Integration API you can override the binding with ?organization=<id or slug>.
Either way, membership is re-verified server-side on every request. A valid key cannot read an organization its owner doesn't belong to — that returns 403, not 404, because the caller authenticated fine and simply isn't a member.
Call GET /api/v1/me to list the organizations a key can reach.
Keeping keys safe
- Treat a key like a password. It carries the permissions of the user who created it.
- Use them server-side only — never in browser code or a mobile app. Public widget traffic doesn't need a key; it's authorised by the agent's public slug and your origin allow-list.
- Create one key per integration so you can revoke one without breaking the rest.
- Revoke immediately if a key is exposed; there's no way to rotate a key in place.