Sandbox
Same host, same code, different universe. The key decides.
Sandbox is not a separate hostname. It is the same API, reached with a key whose id
begins gyv_k_sandbox_ instead of gyv_k_live_.
That is a deliberate choice: there is no base URL to forget to change on the way to production, and no class of bug where half your config points at one universe and half at the other. The mode travels inside the credential, where a human reading a log line, a config file or a support screenshot can see it without looking anything up.
Every project has sandbox. There is nothing to request - see Access.
The mode is a label, not the control
Authentication reads the mode from our records, not from the string you send. You cannot reach live data by editing a prefix.
What differs
- Money is not real. Seed a balance from the faucet on the Wallet screen.
- Data is isolated. Sandbox and live records never mix.
- Four chains do not exist here. Bitcoin, Lightning, Tron and BSC. Everything else - Base, Polygon, Ethereum, Solana - behaves identically to live.
The chains sandbox cannot serve
Our sandbox acceptance runs on the payment provider's sandbox, and four of the networks
we support in live are not fulfillable there. Asking for one is refused with 400 and
details.code of chain_not_in_sandbox.
That code is deliberately not unsupported_chain. The network is real and works the
moment you sign with a live key; told "unsupported", you would go hunting for a mistake
in a request that was correct.
We refuse rather than mint a placeholder. An address that looks real and can never receive is worse than no address at all: you fund it, nothing arrives, and from the outside that is indistinguishable from the platform losing the money.
BTC is not receivable in sandbox at all
Bitcoin and Lightning are BTC's only two chains, and both are on the list above. So
POST /v1/addresses with chain: "bitcoin" and
POST /v1/lightning/invoices both refuse
in sandbox, and there is no third route to a BTC deposit here.
You can still hold BTC - the faucet seeds a BTC balance - so anything downstream of the balance (payouts, transactions, balance arithmetic at 8 decimal places) is testable. What you cannot exercise in sandbox is BTC acceptance. Plan to prove that leg against a live key with a small real amount.
The faucet seeds a balance, not an address
It credits your project's wallet directly, the way a confirmed deposit would have. It
does not send anything to an address, so it emits no deposit.success webhook - if
you are testing your webhook handler, the faucet is not the trigger for it.
Caps are per asset: 1,000 USDT or USDC, 10 BTC, in one call and in total. Generous for any realistic flow, and low enough that you are not testing arithmetic no real balance ever reaches.
Going live
Register a live key, allowlist your production egress IPs against it, and swap the key id and private key in your config. Nothing else changes.
The one thing to re-test rather than assume: any flow on bitcoin, lightning, tron or bsc, because sandbox never ran it.