> ## Documentation Index > Fetch the complete documentation index at: https://docs.jojapi.com/llms.txt > Use this file to discover all available pages before exploring further. # Using JoJ API Keys 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](https://jojapi.com/workspace/api-keys) — including grouping keys into [projects](#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:** ``` X-JoJAPI-Key: YOUR_API_KEY ``` ### 2. Authorization Header Pass your API key directly through the `Authorization` header without any prefix. **Example:** ``` Authorization: YOUR_API_KEY ``` ### 3. Bearer Token Use the `Authorization` header with the `Bearer` scheme followed by your API key. **Example:** ``` Authorization: Bearer YOUR_API_KEY ``` ### 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:** ``` Authorization: Basic BASE64_ENCODED_APIKEY ``` > **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](/consumers/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--Used`, `X-Jojapi--Remaining` and `X-Jojapi--Total-Used` * `X-Jojapi-User-Balance` and `X-Jojapi-Spent-Balance` * `X-Jojapi-Deployment`, and `X-Jojapi-Gateway-Response` on [gateway-generated responses](/gateway/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](https://jojapi.com/workspace/api-keys), 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**. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.