Authorization header.
Creating a key
Send aPOST request to /api/v1/console/keys with a name and optional configuration:
Request fields:
key field in the response is the value you use with the X-API-Key header. It will not appear in any subsequent API call.
Listing your keys
Retrieve all keys on your account withGET /api/v1/console/keys. The response includes metadata for each key but not the full key value — only the first 12 characters (key_prefix) are returned.
Revoking a key
Pass the key’s UUID toDELETE /api/v1/console/keys/{id}. Revocation takes effect immediately — there is no grace period.
Using a key to call external endpoints
Pass the full key value in theX-API-Key header when calling any /api/v1/external/* endpoint:
Best practices
- One key per application. Keep your keys scoped to a single service so you can revoke one without affecting others.
- Use descriptive names. Labels like
"Arbitrage Bot – Staging"or"Dashboard – Production"make it easy to identify keys in the list and in usage logs. - Revoke unused keys. If a key has not been used in weeks (check
last_used_at), revoke it to limit your attack surface. - Store keys in environment variables. Never hardcode a key in source code or commit it to version control.
- Request only the permissions you need. If your application only reads arbitrage data, set
permissionsto'["read:arbitrage"]'rather than the full default set.
