Skip to main content

​
What the sandbox does

The Conduit sandbox cluster (https://api.sandbox.conduit.financial) mirrors production with three differences designed to make integration safe and deterministic: Compliance and banking are isolated — no third-party compliance or banking calls are made, and fiat settles synthetically. Crypto is different: the deployed sandbox (https://api.sandbox.conduit.financial) runs a real public testnet, so a crypto transfer a newly-provisioned customer makes on a supported chain (Base, Ethereum, Polygon, Solana) broadcasts and is signed for real (Use a real testnet). Fiat stays deterministic and synthetic; crypto is real on-chain.
  1. Compliance and Travel Rule are isolated. Sandbox builds never reach upstream compliance services. Outcomes are determined locally by your request data — specifically, by the destination address suffix, fiat account-number suffix, magic bankName value, or registered-address magic value you submit.
  2. Crypto runs on a real public testnet. The deployed sandbox delivers and settles crypto on a real testnet: a crypto transfer that leaves a wallet — a /v2/payouts withdrawal, and the crypto source leg of an offramp or a crypto conversion — broadcasts and is signed on a real network, verifiable on that network’s block explorer. This covers the supported testnet chains (Base, Ethereum, Polygon, Solana); Tron and Stellar are not transactable on this posture. A newly-provisioned customer gets real-testnet wallets; fund them from a faucet, and sign with a real passkey or a machine stamp (simulate/cosign returns 409 SANDBOX_SIGNING_SIMULATION_UNAVAILABLE). A wallet provisioned before real testnet was enabled cannot transact — its payout/order is refused with 422 LEGACY_MOCK_WALLET_UNSUPPORTED, so create a new customer. See Use a real testnet for the custody rule and the supported testnets.
  3. Scenario forcing via magic values. Specific address suffixes, account-number suffixes, and magic field values deterministically trigger compliance, Travel Rule, and chain outcomes. See the per-flow guides below.
Your sandbox API key is scoped to your sandbox organization and never reaches production.

​
Sandbox vs. production at a glance

Every crypto payout and order waits for a real signature — sandbox never auto-signs. On the deployed sandbox a non-custodial transfer parks at transaction.awaiting_signature: approve with a real passkey, or with a machine-signer stamp at POST /v2/signing-requests/:id/approve (see Use a real testnet and Machine-signer stamping). The signing and enrollment levers (simulate/cosign, simulate-stamp, mark-enrolled, ceremony-stamp, simulate-approval-gate) return 409 SANDBOX_SIGNING_SIMULATION_UNAVAILABLE. A wallet provisioned before real testnet was enabled cannot transact at all — its payout or order is refused at creation with 422 LEGACY_MOCK_WALLET_UNSUPPORTED; create a new customer. Production requires a real customer signature; sandbox mirrors that requirement.
Sandbox-only conveniences (not behavior you get in production).
  1. Fiat liquidity is already there. In production the accounts behind every fiat payout must be funded before a payout can draw on them; in sandbox they already are — a funding account exists for every currency sandbox supports, so your first fiat payout in a supported currency never waits on it. Crypto is different on the real-testnet sandbox: a crypto delivery (an onramp, or a conversion’s destination leg) draws on a shared per-chain testnet float that is finite, so it can occasionally be delayed while that float is replenished, and a per-chain, per-UTC-day cap bounds how much each customer can draw. See ONRAMP orders — Errors for the cap.
  2. Crypto broadcast and finality are real. On the deployed sandbox a crypto transfer broadcasts on a real testnet and reaches finality in minutes, verifiable on the network’s explorer — there is no simulate/confirm shortcut for it. Wallet creation and fiat deposits still settle without any manual action, so you can drive flows end-to-end through HTTP alone; fund crypto wallets from a faucet (see Use a real testnet).
  3. orders/:id/simulate/rate-lock-expired cancels orders in about 3 seconds via an immediate sweep tick (not the 30-second scheduled sweep).
  4. Forced-failure reasons round-trip 1:1 for transactions. transactions/:id/simulate/terminal { outcome: "failed", reason } and address-suffix scenarios flow the supplied text to the polled GET and to the webhook payload identically. A payout failed before any transfer was sent is cancelled (transaction.cancelled), because that is the only way a payout ends before it reaches a rail. orders/:id/simulate/conversion-failed { reason } keeps the reason on the cancelled transfer; the order carries the standard text for its failure code.
  5. Force-failing a payout at the cosign gate frees the wallet immediately; the next payout on the same wallet is accepted within milliseconds, with no cooldown.

​
Where to start

New to the sandbox? Follow the Quickstart to complete your first end-to-end transaction in about 10 minutes. For detailed guides on each transaction type:
  • Deposits — fiat simulation, real testnet wallet funding, and the sender-information gate
  • Withdrawals — crypto and fiat withdrawal simulation, chain and cosign scenarios
  • Conversions — the FX conversion leg inside orders, rate-stale and provider-unavailable paths
  • Onramps — fiat-in to crypto-out orders, full lifecycle
  • Offramps — crypto-in to fiat-out orders, full lifecycle
Each per-flow page above covers happy paths plus the failure scenarios specific to that flow (deposit compliance, withdrawal cosign, conversion failures, etc.). Copy-paste recipes live inline in those pages.

​
Driving scenarios

Five mechanisms cover every meaningful failure mode:
  • Crypto destination address suffix (last 8 hex chars on EVM; last 8 Base58 chars on Tron/Solana) — drives compliance and Travel Rule outcomes for crypto withdrawals. See Withdrawal failure paths and Travel Rule scenarios.
  • Registered-address magic values — drive the sanctions-screening verdict when registering a wallet address: an address starting with 0x999 parks the registration as pending_screening (202), resolved self-service via POST /v2/sandbox/wallets/registered-addresses/:id/simulate/compliance-decision; dedicated magic addresses force an immediate rejection (409). See Registered Addresses — Testing in sandbox.
  • Fiat account-number suffix (last 8 digits of recipient.accountNumber for payouts, or senderInfo.accountNumber for source deposits) — drives settlement outcomes for fiat payouts and source-funding compliance outcomes for fiat source deposits. See Withdrawals, Deposits, and ONRAMP orders.
  • autoPayout.recipient.bankName magic value (SANDBOX_AML_REJECTED, SANDBOX_AML_SANCTIONED) — drives compliance outcomes on the fiat payout leg of OFFRAMP orders. See Offramps.
  • POST /v2/sandbox/.../simulate/* endpoints — advance asynchronous state without waiting for automatic timers: chain finality (payouts/:id/simulate/confirm), fiat settlement (payouts/:id/simulate/settled), order-level failure (orders/:id/simulate/conversion-failed), rate-lock expiry (orders/:id/simulate/rate-lock-expired), counterparty webhook overrides (payouts/:id/simulate/counterparty-webhook), and transaction-level terminal simulation (transactions/:id/simulate/terminal) for withdrawals, deposits, onramps, and offramps. Internal-transfer rows are not simulatable. Conduit-internal movements (conversion legs, ops-to-ops sweeps) settle automatically; a conversion’s failure path is testable via orders/:id/simulate/conversion-failed. See Withdrawal failure paths.
Address/account-number suffixes set the desired terminal state at creation time; simulate-* endpoints let you inject failures or pre-empt any automatic timer for fine control.

​
Notes

  • Suffixes are matched against the last 8 characters of the rail-canonical destination address (lowercased hex for EVM; Base58 verbatim for Tron and Solana).
  • Magic suffixes are sandbox-only. Sending the same address against the live API screens through real compliance and Travel Rule services — the suffix has no meaning there.
  • Real-customer collision probability for an 8-char hex suffix is ~1 in 4.3 billion. Don’t use magic suffixes in production address books.
  • The Sandbox group at the end of the API Reference enumerates every sandbox-only endpoint. These routes exist only on the sandbox host; calling them against the live API returns 404.

​
See also