Skip to main content
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 for who can manage what.
1

Open API Keys for your team

In Portal, switch to the team the key is for, then open API Keys.
2

Create and name the key

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.
3

Copy the key

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.
4

Use it in the x-api-key header

Send the key in the x-api-key header on requests to api.jup.ag. See Getting Started 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.
New keys, permission changes, renames, and deletions propagate to the gateway within about 15 seconds. All key changes are recorded in the 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: 
{
  "code": 403,
  "message": "API key does not have access to this endpoint"
}
See Response Codes 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 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 rules to limit abuse.

Firewall

Block abuse and rate-limit traffic to keys you use in client apps.

Organisations & Teams

See who can create and manage a team’s API keys.

Rate Limits

Rate limits apply per organisation, not per key.

Getting Started

Sign up, get a key, and make your first request.