YOUR_API_KEY with one of your actual keys.
1. X-JoJAPI-Key Header
Send your API key via the customX-JoJAPI-Key HTTP header.
Example:
2. Authorization Header
Pass your API key directly through theAuthorization header without any prefix.
Example:
3. Bearer Token
Use theAuthorization header with the Bearer scheme followed by your API key.
Example:
4. Basic Token
Send your API key using HTTP Basic Authentication: theAuthorization header contains the word Basic, followed by the base64 encoding of YOUR_API_KEY:YOUR_API_KEY — the key doubles as both username and password.
Example:
Note:
To encode:
echo -n "YOUR_API_KEY:YOUR_API_KEY" | base64
Which Method Should I Use?
All four methods are interchangeable and equally secure: the gateway validates your key and strips the credential header before forwarding the request, so the API provider never sees your JoJ API key — whichever method carried it.- X-JoJAPI-Key is the canonical choice. It uses a dedicated header, so it never conflicts with anything else in your request.
- Bearer is the industry-standard token scheme. Use it with anything that offers a standard “API token” or “Bearer token” field — HTTP clients, Postman collections, no-code platforms (Zapier, Make, n8n), AI agent frameworks — or when migrating existing clients that already send
Authorization: Bearer, so only the base URL and the token need to change. - Basic exists for legacy software and integrations that can only send username/password credentials; the key doubles as both.
- Authorization (raw) is a terse fallback for tools that let you set the header’s value but not its scheme.
If the API you call uses theAuthorizationheader for its own authentication, send your JoJ key viaX-JoJAPI-Key. The gateway recognizes its own keys by thejk_prefix: anAuthorizationheader that doesn’t carry ajk_key is passed through to the API untouched, so both credentials can travel in the same request. For the same reason, gateway authentication viaAuthorizationand the API’s ownAuthorizationheader can’t be combined — there is only one such header.
Restricting a Key to Specific APIs
By default, an API key works on every API you are subscribed to. You can limit a key to a specific set of APIs from Workspace → API Keys: click API access on a key, turn off Access to all APIs, and tick the APIs the key is allowed to call. When a key is restricted, the gateway rejects any request it makes to an API outside its allowed list with a403 response. This is useful for separating environments, sharing a narrowly-scoped key with a teammate, or limiting exposure if a key is ever leaked. You can change a key’s access — or return it to all APIs — at any time.