Authentication
The Sangho API uses API keys to authenticate requests. Each App has a public key and a secret key.
Key Types
| Type | Prefix (prod) | Prefix (test) | Usage |
|---|---|---|---|
| Public Key | pk_prod_ | pk_test_ | Client-side SDK initialization only |
| Secret Key | sk_prod_ | sk_test_ | Server-side requests only — never expose |
The environment is called prod, not live — the sk_prod_ key is the only one that triggers real transactions.
Your pk_/sk_ keys are the same whether your App is an ordinary merchant App or an App with Platform Partner status — that status doesn’t add new keys, it only grants the right to call the connect.* (marketplace) endpoints. See Marketplace & Connect.
HTTP Header Usage
Add your secret key in the Authorization header of each request, prefixed with Bearer.
Sandbox vs. Production
sk_test_ keys point to the Sandbox database — no real transactions. sk_prod_ keys trigger real transactions.
Never use a sk_prod_ key in frontend or client-side JavaScript code. It could be exposed and compromised.
Key Rotation
- 1. Create a new key from Dashboard → Settings → API Keys
- 2. Update your server configuration with the new key
- 3. Revoke the old key — it is immediately invalidated
- 4. All requests with the old key will return 401
Idempotency Key
For critical POST requests (PaymentIntent, Refund), add a unique Idempotency-Key header — a UUID, for example. If you resubmit the same request with the same key within 24h, Sangho returns the response already produced (with the Idempotency-Replayed: true header) instead of creating a duplicate.
If the same key is reused with a different request body, Sangho rejects the request with a 409 IDEMPOTENCY_CONFLICT error rather than guessing which version to process.
Authentication Header
With Idempotency Key
Authenticated Request Example
Response — Invalid Key (401)
Retrieve your keys from Dashboard → Developers → API Keys. Test keys are visible upon registration, with no KYC required.