Skip to main content
Beta FeatureThe Transaction Simulations feature is currently in beta. API endpoints and behavior may change as we continue to refine the product. Simulation endpoints are available in development environments only — production returns 404 Not Found.
Trigger a transfer transaction against a configured payment route, exactly as if a real deposit had triggered it. Use this to test the transfer and webhook lifecycle end-to-end.

Prerequisites

Before you can simulate a payment route, you must create a payment route in the sandbox environment. The payment route creation endpoint is separate from the simulation endpoint. For onramps (fiat → crypto), create a payment route:
For offramps (crypto → fiat), first create a payment account, then create a payment route:
The response includes the id field — this is your paymentRouteId to use in simulation requests. See the Onramps and Offramps documentation for complete details on creating payment routes.

Endpoint

The /v1/simulate/automations endpoint has been renamed to /v1/simulate/payment-routes. The old path remains available as a deprecated alias during migration. Update your integrations to use /v1/simulate/payment-routes as the deprecated endpoint will be removed in a future release.
Supported payment route types:
  • MXN payment routes — Both onramps (SPEI → crypto) and offramps (crypto → SPEI)
  • USD payment routes — Both onramps (ACH/wire → crypto) and offramps (crypto → ACH/wire)
Simulating any other payment route type returns 422 Unprocessable Entity.

Supported chains

Payment routes can only be created on the following testnet chains in the sandbox environment:
  • Ethereum Sepolia
  • Avalanche Fuji
  • Solana Devnet
  • Polygon Amoy
  • Base Sepolia
Once you have a payment route on a supported chain, you can simulate transfers against it.

Minimum amount

Onramp and offramp simulations require a minimum amount of $2.

Headers

Body

Example request

Response

The response format depends on the payment route type.

MXN payment routes (synchronous)

MXN payment route simulations return immediately with the transaction ID:
200 OK
The transaction starts in pending and progresses asynchronously, just like one triggered by a real deposit. Your webhook URL receives the same transactionTransfer webhooks as a real transfer:
  • action created — sent when the transfer is initiated.
  • action updated — sent on intermediate status changes (for example, awaiting_transferprocessing).
  • action completed — sent when the transfer settles.
See Webhooks for payload schemas.

USD payment routes (asynchronous)

USD payment route simulations return HTTP 202 to indicate the request was accepted and the simulation is processing asynchronously:
202 Accepted — USD onramp
202 Accepted — USD offramp
USD simulations trigger real webhook callbacks asynchronously. Your webhook URL receives transactionTransfer webhooks as the simulation progresses through the transfer lifecycle.

Errors

Behavior notes

  • No real funds move. Simulations are fully mocked end-to-end — you don’t need to pre-fund anything.
  • MXN simulations create immediate transaction records. The transaction is queryable via the transactions API and fires webhooks as it progresses.
  • USD simulations process asynchronously. The 202 response indicates the simulation request was accepted. Webhooks fire as the underlying providers process the simulated deposits.

Example