Authenticate your integration
Give each service the credentials and partner context it needs to perform its work.
Send the API key in the Authorization header on your backend requests.
Authorization: Bearer your-api-key
Keys have scopes and may be bound to a partner. These are separate properties: access to a method does not remove its requirement for a specific partner context.
Partner and administrative access
| Operation family | Required context |
|---|---|
/partner/* |
Partner-bound key with partner:read |
| Users, webhooks, usage and partner-specific analytics | Partner context; consult the method's scope in the reference |
| Protocol yield history and shared market analytics | A permitted read or partner:read key |
/partners/* |
Administrative partner:admin scope |
/keys/* |
Administrative keys:admin scope |
| Protocol-wide reconciliation report | Administrative read scope; partner keys are rejected |
/status |
Public, no key required |
The existing partner:read scope also authorizes some partner operations that create records, including users and webhooks. Do not infer read-only behavior from the scope name; use each method's documented requirements.
Store and rotate credentials
Store the credential in your backend's secret configuration. Do not embed a partner or administrative key in a shipped browser application, a mobile bundle or a customer-visible code sample.
Key creation returns the secret once. Subsequent list responses mask it. When rotating an integration credential, verify the replacement in the intended environment before revoking the previous credential.
Diagnose authentication failures
401 indicates a missing or invalid credential. 403 can indicate a missing scope, a disabled partner or a missing partner binding. An administrative key can therefore fail on a partner-scoped method even if it works for account administration.
Check the URL, credential and partner binding together. A sandbox key cannot stand in for a Partner API onboarding credential.