Documentation
Authentication
How API keys work, which key to use where, and why some dashboard actions ask you to confirm it is really you.
Key types
| Key | Where it lives | What it can do |
|---|---|---|
| sk_test_… | Your server only | Everything your account can do in the sandbox. Shown once, stored as a hash. |
| pk_test_… | Browser or mobile app | Only tokenisation for checkout. Safe to embed in front-end code. |
| rk_test_… | Specific services | Only the scopes you grant, e.g. read-only access for a reporting job. |
Live keys
sk_live_ keys cannot be created yet. They will exist only after live processing is approved for your account.Sending the key
Authenticate with HTTP Bearer authentication. Requests without a valid key return 401 authentication_required.
curl http://localhost:4610/v1/balance \
-H "Authorization: Bearer sk_test_..."Restricted keys and scopes
Restricted keys follow least privilege. Scopes are written as resource:read or resource:write:
| Scope | Allows |
|---|---|
| payment_intents:read | Retrieve and list Payment Intents |
| payment_intents:write | Create, confirm, capture and cancel |
| refunds:write | Create refunds |
| payouts:read | Retrieve and list payouts |
| events:read | Retrieve and list events |
A request outside the key's scopes returns 403 permission_denied.
Step-up for dashboard actions
Some actions are too sensitive to rely on an existing session alone: adding or changing a bank account, creating payouts, creating API keys, changing team roles and changing two-factor settings. The dashboard asks you to re-authenticate if you have not done so in the last ten minutes. Dashboard API calls that need it return 401 step_up_required.