Environments & modes
One base URL for everything. The token you send decides whether it moves real money.
Base URL
There is a single host. Sandbox and live are not separate domains — you never rewrite a URL to switch modes, so the same deployed code works in both.
https://api.oropocket.com/partnerTwo tokens, one account
Your account always holds two keys at once — one per mode. They are independent: your sandbox key keeps working while live is still under review, and regenerating one never touches the other.
| Token | What it does |
|---|---|
| oro_live_… | Live. Real money, real pricing. The receiver gets a push notification and an email. |
| oro_test_… | Sandbox. Same endpoints, persistent test data, live prices, simulated settlement. OTP is always 1234. |
How the mode is chosen
Purely by the token prefix. There is no mode parameter, header or query string — send oro_test_ and the call is sandboxed, send oro_live_ and it settles for real.
curl https://api.oropocket.com/partner/prices \
-H "Authorization: Bearer oro_test_xxx"Every response — success or failure — echoes a top-level mode field, so the answer to "which environment did that actually hit?" is always in the payload you already have.
{
"success": true,
"request_id": "req_9f2c…",
"mode": "sandbox",
"data": { /* endpoint payload */ }
}Token lifetime
Tokens have no expiry. There is no refresh flow and nothing to renew on a schedule. A key stays valid until one of two things happens: you regenerate that mode's key — which instantly invalidates the previous one — or an admin revokes it.
Mode errors
These three are about the mode, not the call you made — the request itself may be perfectly valid.
| Code | Meaning |
|---|---|
| LIVE_NOT_ENABLED | 403 — Live is not activated yet, compliance is still pending. Sandbox keeps working. |
| SANDBOX_DISABLED | 403 — Sandbox access has been disabled for your partner. |
| PARTNER_DISABLED | 403 — Master kill-switch. Both modes are disabled. |
The capability model
Being in the right mode is not enough on its own. Every call is additionally gated per capability: your partner profile carries a list of the capabilities you hold, and anything outside it returns 403 API_NOT_ALLOWED — in both modes, identically.
| Capability | Unlocks |
|---|---|
| pricing | Live gold, silver and BTC prices, and the quotes every trade starts from. |
| receiver | Check whether a mobile number can receive assets before you send to it. |
| send | Partner-funded sends: move assets out of your own wallet to a user. |
| transactions | Transaction lookups and the unified activity feed across your users. |
| balance | Portfolio and balance reads for a user. |
| embed | Mint hosted-embed sessions and run the embed handshake. |
| users | Create, list and inspect the users you onboarded. |
| buy | Server-to-server buys on a user's behalf, billed to your partner wallet. |
| sell | Server-to-server sells, settling into the user's INR wallet. |
| kyc | Submit and track end-user KYC. |
| bank | Add and verify an end user's bank account. |
| withdraw | Pay INR out to an end user's bank account. Sensitive — this moves real money. |
| gift | User-to-user gifting, funded from the end user's own balance. |
| delivery | Physical coin delivery orders. Sensitive — real goods ship, billed to your wallet. |
You manage these yourself. Pick what you are building on the Use cases page and we enable exactly the capabilities that use case needs — or toggle individual capabilities directly. Changes apply to your next API call, in both modes.
Next
Read Sandbox & test mode for the magic values and the reset endpoint, and Errors & rate limits for the full error envelope and code list.