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 projects and API keys — including grouping keys into projects, creating new keys, deleting existing ones, restricting a key to specific APIs, hiding JoJ API headers from a key’s responses, 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.

​
Projects

Every API key belongs to a project. A project groups the keys of one app, client or environment, so you can find them quickly, see their usage together and keep the list tidy as it grows. Manage them from Workspace → Projects & API Keys: the project switcher shows one project’s keys or all of them, and the menu next to it renames or deletes the selected project.
  • Default project. Your first key is in a project named Default, and keys created before projects existed were placed there too. You can rename it like any other project.
  • Choosing a project. Create API Key asks which project the key belongs to, along with an optional name. A key stays in that project for good: keys can’t be moved, so a project’s usage history is always the history of its own keys. To reorganize, create a key in the other project and delete the old one once nothing uses it (the Last used column tells you).
  • Limits. Up to 25 projects per account and 50 API keys per project. Deleted keys don’t count.
  • Deleting a project. A project can be deleted once it has no keys left. Its usage stays in your analytics, marked as deleted.

​
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 → Projects & 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.

​
Hiding JoJ API Headers

Every response the gateway returns carries its own response headers: usage and remaining quota per billable object, your balance on pay-as-you-go plans, and the deployment that answered. When another platform calls APIs with your key — a bridge that lists an API elsewhere, or a reseller that passes responses on to its own customers — you may not want those headers to travel on. From Workspace → Projects & API Keys, open a key’s menu, choose JoJ API headers and turn on Hide JoJ API headers. Responses to that key then carry none of the gateway’s headers:
  • X-Jojapi-<slug>-Used, X-Jojapi-<slug>-Remaining and X-Jojapi-<slug>-Total-Used
  • X-Jojapi-User-Balance and X-Jojapi-Spent-Balance
  • X-Jojapi-Deployment, and X-Jojapi-Gateway-Response on gateway-generated responses
The API’s own headers and the CORS headers stay, and nothing else changes: usage is counted and billed as before, and request logs and analytics still show every request. Gateway-generated errors keep their status code and JSON body, so the calling platform can still tell a quota or rate-limit error apart. Keys with the setting show a Headers hidden badge; a change takes effect within two minutes.
APIs still served by the classic gateway send these headers regardless of the setting.

​
Per-Key Analytics & Last Used

Every request is attributed to the API key that made it:
  • Analytics (Workspace → your subscription → Analytics): the Project and API Key filters scope every chart — requests, usage, latency, spent balance — to one project or a single key. Under the chart, Usage by project and Usage by API key break down requests, share of traffic, average latency and pay-as-you-go spend over the selected period.
  • Request logs: each entry shows which key made the request and its project, and the list can be filtered to one key.
  • Last used (Workspace → Projects & API Keys): each key shows when it last made a request. Requests rejected for quota or access reasons count too — the column answers “is this key still in use anywhere?”, which makes it a reliable check before deleting a key.
Deleting a key stops it from authenticating immediately, but its name remains attached to its historical usage and logs — so rotating keys never costs you analytics history. To get the most out of per-key analytics, give each application or environment its own key and name it, or its own project: the breakdown then reads as “production / staging / mobile app” instead of masked key endings.
Per-key attribution began on August 23, 2026. Usage from before that date appears aggregated as Before key tracking.