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.
Going live is two changes: 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 with everything behind the API simulated. You
drive the outcomes that would otherwise be decided for you: verification
decisions, treasury funding, fiat deposits, and wallet deposits, through
endpoints under /api/sandbox/simulate/*.
Exchange rates in sandbox are fixed and deterministic, so assertions in your test suite are stable. USD to USDC is at par.
Because webhooks are really delivered and really signed in sandbox, the consumer you build there is production ready as is, with no environment branches. See Sandbox Testing.
Live
Live moves real money. Access requires your organization to be fully
onboarded: partner terms executed and your own business verification
approved. Until both are done, live calls return
403 partner_tos_required or 403 partner_kyb_required.
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.
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.