Get started

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/partner

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

TokenWhat 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 */ }
}
That echo is the cheapest guard you can build against a mis-wired deploy. Log it, or assert on it in your integration tests, and a test key that leaked into production announces itself on the very first call.

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.

Regeneration takes effect immediately, with no grace period. Roll the new key out to every service that holds the old one before you press the button.

Mode errors

These three are about the mode, not the call you made — the request itself may be perfectly valid.

CodeMeaning
LIVE_NOT_ENABLED403 — Live is not activated yet, compliance is still pending. Sandbox keeps working.
SANDBOX_DISABLED403 — Sandbox access has been disabled for your partner.
PARTNER_DISABLED403 — 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.

CapabilityUnlocks
pricingLive gold, silver and BTC prices, and the quotes every trade starts from.
receiverCheck whether a mobile number can receive assets before you send to it.
sendPartner-funded sends: move assets out of your own wallet to a user.
transactionsTransaction lookups and the unified activity feed across your users.
balancePortfolio and balance reads for a user.
embedMint hosted-embed sessions and run the embed handshake.
usersCreate, list and inspect the users you onboarded.
buyServer-to-server buys on a user's behalf, billed to your partner wallet.
sellServer-to-server sells, settling into the user's INR wallet.
kycSubmit and track end-user KYC.
bankAdd and verify an end user's bank account.
withdrawPay INR out to an end user's bank account. Sensitive — this moves real money.
giftUser-to-user gifting, funded from the end user's own balance.
deliveryPhysical 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.

Grant only what you use. Capability checks fail closed, so a narrow key limits the blast radius if it ever leaks — and turning a capability back on takes seconds.

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.