Environments
Two hosts, two key prefixes, fully partitioned data, and how versioning works.
Rasto Business provides two environments: sandbox and live. They are the same API, with the same endpoints, shapes, and statuses. They differ in the host, the key prefix, and whether what runs behind them is real.
| Sandbox | Live | |
|---|---|---|
| Base URL | https://sandbox.rasto.co | https://api.rasto.co |
| Key prefix | sk_test_ | sk_live_ |
| Verification and banking | Simulated | Real |
| Money | None moves | Real |
| Webhooks | Really delivered, really signed | Real |
| Simulation endpoints | Available | 403 sandbox_only |
Data is fully partitioned. A sandbox customer does not exist in live, and
partner_reference_id uniqueness is scoped per environment, so the same
reference id can exist in both.
Chain-bearing objects (wallets, balances, operations, conversions, payouts,
transactions, corridors, quotes) carry network (testnet in sandbox,
mainnet in live) beside chain. chain is the same in both, so your
integration never branches on it.
Going live is two changes in your code: the base URL and the key. A key
used against the wrong host is rejected with 401 environment_mismatch
rather than operating on the wrong data.
Sandbox
Sandbox runs the full product on testnets. Bank rails, verification
decisions, and exchange rates are simulated, while wallets and stablecoin
deliveries are real testnet transactions. You drive the outcomes that would otherwise be decided for you (verification
decisions, treasury funding, and fiat deposits) through endpoints under
/api/sandbox/* that mirror the resource they act on.
Exchange rates in sandbox are fixed and deterministic, so assertions in your test suite are stable. USD to USDC is at par.
Webhooks are delivered and signed exactly as in live, so the consumer you build against sandbox needs no environment branches. See Sandbox Testing.
Live
Live moves real money. Access opens once onboarding is complete in the
dashboard: your executed Partner Terms on record, your company's own
acceptance of our terms, its business verification approved, and your
live wallet keys registered and activated. Until then, live calls return
403. For the codes, see
Authentication.
Versioning
The /api prefix is a namespace, not a version. Breaking changes ride the
optional Api-Version header as an ISO date:
curl -s $BASE/api/customers -H "Api-Key: $KEY" -H "Api-Version: 2026-08-01"
Omitting the header pins you to the oldest supported version. That is
deliberate: a deploy can never move an integrated partner onto a breaking
change. Requesting a version we do not serve returns
400 unsupported_api_version and lists the ones we do.
Supported today: 2026-08-01. Every authenticated response echoes the
version it was served under in an api-version header.
Backwards-compatible changes ship without a version bump: new endpoints, new optional request parameters, new response fields, new enum values, and new event kinds. Build your integration to ignore unrecognized response fields and to tolerate unfamiliar enum values.
Breaking changes are announced in the Changelog with a migration note before they reach live, and they arrive under a new date. Releasing a new version does not affect existing ones: you upgrade by changing the header when you are ready.