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.
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.