> ## Documentation Index
> Fetch the complete documentation index at: https://dev.jup.ag/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# API Keys
> Create API keys, restrict them to specific APIs, and manage their lifecycle.
An API key authenticates your requests to `api.jup.ag`. You pass it in the `x-api-key` header. By default a key can call every Jupiter API, so keep it secret. Permissions let you restrict a key to specific APIs, so a key used in a client app, or one that leaks, can only reach the APIs you allowed.
## Create a key
API keys belong to a team. You can create and manage a team's keys if you are a member of that team, or an owner or admin of the organisation. See [Organisations & Teams](/portal/organisations) for who can manage what.
In [Portal](https://developers.jup.ag/portal), switch to the team the key is for, then open **API Keys**.
Create a key and give it a name. Names are unique within a team, so use something that identifies where the key runs, for example `web-app-prod` or `backend-staging`.
The full key is shown **only once**, at creation. Copy it now and store it securely. After you close this dialog, Portal shows only the first and last few characters, and there is no way to reveal the full key again.
Send the key in the `x-api-key` header on requests to `api.jup.ag`. See [Getting Started](/portal/setup) for a request example.
## Managing keys
* **Rename** a key from its detail view in Portal.
* **Delete** a key you no longer use or that may be exposed.
* **Permissions** can be changed at any time from the key's detail view. See [Permissions](#permissions).
New keys, permission changes, renames, and deletions propagate to the gateway within about 15 seconds. All key changes are recorded in the [audit log](/portal/security#audit-log).
## Permissions
By default a key can call every Jupiter API. Permissions restrict a key to an allow-list of products. Once you set the list, the key can only call the endpoints those products cover, and a request to any other endpoint is rejected.
In Portal you toggle which products a key can call: Swap, Tokens, Price, Trigger, Recurring, Portfolio, Lend, Send, Studio, and Prediction. Matching is by path prefix and is case-sensitive.
The **Swap** permission also covers `/tx/v1/submit`, so a key limited to Swap can submit transactions too.
### Example: a key scoped to Price and Tokens
A key allowed only the Price and Tokens products can call those APIs. A request to a Swap endpoint like `/swap/v2/order` is rejected at the gateway with `403 Forbidden`:
```json theme={null}
{
"code": 403,
"message": "API key does not have access to this endpoint"
}
```
See [Response Codes](/portal/responses) for the other gateway responses.
## Best practices
* **One key per app or environment.** Use separate keys for your web app, mobile app, and backend, and separate keys for staging and production. If one is exposed, you delete only that key. Your [rate limit](/portal/rate-limits) is shared across the organisation, so extra keys do not raise it.
* **Least privilege.** Give each key only the permissions its app needs. A key used in a client app should be limited to the APIs that app actually calls.
* **Rotate keys.** Replace keys periodically, and whenever one might be exposed. Create the new key, move traffic to it, then delete the old one. For a key you use in a client app, add [firewall](/portal/firewall) rules to limit abuse.
## Related
Block abuse and rate-limit traffic to keys you use in client apps.
See who can create and manage a team's API keys.
Rate limits apply per organisation, not per key.
Sign up, get a key, and make your first request.