Skip to main content
JoJ API Keys provide secure access to APIs listed on the JoJ API Marketplace, allowing you to integrate these APIs into your software and applications. You can manage your API keys — including creating new keys, deleting existing ones, restricting a key to specific APIs, or assigning custom names for easier organization. JoJ API supports multiple authentication methods using your API keys. Below are the available options, along with brief explanations and usage examples — replace YOUR_API_KEY with one of your actual keys.

1. X-JoJAPI-Key Header

Send your API key via the custom X-JoJAPI-Key HTTP header. Example:

2. Authorization Header

Pass your API key directly through the Authorization header without any prefix. Example:

3. Bearer Token

Use the Authorization header with the Bearer scheme followed by your API key. Example:

4. Basic Token

Send your API key using HTTP Basic Authentication: the Authorization 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 the Authorization header for its own authentication, send your JoJ key via X-JoJAPI-Key. The gateway recognizes its own keys by the jk_ prefix: an Authorization header that doesn’t carry a jk_ key is passed through to the API untouched, so both credentials can travel in the same request. For the same reason, gateway authentication via Authorization and the API’s own Authorization header 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 a 403 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.