Authentication
API keys — pk_/sk_, sandbox or production by prefix — are real, working credentials. Today they authorize one endpoint; every other resource in the API Reference is authorized by your dashboard session instead. Both are documented below rather than picking one story.
sk_…Secret
Server only
Currently authorizes the developer probe endpoint. Never ship it in a mobile app or a browser bundle.
Which credential authorizes which call
The Payments, Payouts, Refunds, Cards, Customers and Invoices endpoints in the API Reference currently require your dashboard session (the bearer token issued at sign-in), not an sk_ key. The sk_/pk_ key mechanism below is real and enforced — it's just scoped to GET /api/v1/developer/ping and POST /api/v1/developer/sandbox/:kind so far. This is a known gap, not a design choice to hide.
Making a request
Pass your secret key as a bearer token. A missing or malformed header returns 401 unauthorized.
curl https://binkpay.net/api/v1/developer/ping \
-H "Authorization: Bearer sk_test_51H..."Sandbox and production
The prefix tells you which mode a key belongs to, so a test key can never touch live funds by accident.
| Key | Mode | Behaviour | Limits |
|---|---|---|---|
sk_test_… | Sandbox | Test data, no money moves | Unlimited |
sk_live_… | Production | Real funds, real customers | Rate limited |
Rotating a key
Rotate in this order. Revoking before the new key is live creates a gap in service.
- Create the new key in Settings → Developers.
- Deploy it to every server that calls the API.
- Confirm traffic is arriving on the new key.
- Revoke the old key. Revocation is immediate and cannot be undone.
Never commit secret keys
A secret key is shown once in full, then masked (sk_test_••••••1a2b) everywhere in the dashboard. Store it in your environment or secret manager, never in source control.
Was this page helpful?