Simulate a crypto transfer into a sandbox order's funding address
Sends a synthetic crypto transfer to the funding address of an order created with no source — the address the order publishes in depositInstructions. Funding addresses are Conduit-managed and carry no client-visible id, so the order id is the only handle for funding one. It addresses the order’s funding address, not the order itself: the customer’s other open orders on that asset and chain publish the same address, and the funds go to the oldest order they can cover, exactly as a real send would. Whether the sending address is registered is the only gate, and it is enforced here exactly as in production. Pass a sourceAddress the customer has already registered (POST /v2/customers/{customerId}/wallets/registered-addresses) and the funds fund the order; pass one that is not registered and they are sent straight back, with no movement on the order. Omitting sourceAddress gives you a sender that was never registered, so it takes that same return. sourceAddress: null and originator are both rejected: a transfer with no sender cannot be sent back, and sender identity does not open this gate. Send less than the order’s total debit to under-fund it, more to leave a remainder that goes back to the sender. Accepts the order in any status, including expired and cancelled: funding an address after its order has expired is exactly how an unclaimed transfer arises in production. The response is the order as of the call. Watch it with GET /v2/orders/{orderId}, GET /v2/transactions and the transaction.* webhooks.
Authorizations
Path Parameters
Body
completed, frozen, returned 1 - 255^(?:(?:\d\d[2468][048]|\d\d[13579][26]|\d\d0[48]|[02468][048]00|[13579][26]00)-02-29|\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\d|30)|(?:02)-(?:0[1-9]|1\d|2[0-8])))T(?:(?:[01]\d|2[0-3]):[0-5]\d(?::[0-5]\d(?:\.\d+)?)?(?:Z))$1 - 1281 - 255- Option 1
- Option 2
pending_confirmation, finalized Response
^ord_[0-9A-Za-z]{22}$^cus_[0-9A-Za-z]{22}$pending, succeeded, failed, cancelled onramp, offramp, conversion - Option 1
- Option 2
source, destination ISO 8601 timestamp
"2026-01-15T09:30:00.000Z"
ISO 8601 timestamp
"2026-01-15T09:30:00.000Z"
^txn_[0-9A-Za-z]{22}$Client-supplied reference, unique per resource within your organization. 1-255 characters from A-Za-z, 0-9, underscore, hyphen, colon, and period — no spaces.
^[A-Za-z0-9_\-:.]{1,255}$The funding resource, when the order named one. Omitted entirely on a deposit-funded order (created without a source): the funding wallet is Conduit-managed infrastructure with no client-resolvable id, and depositInstructions carries the address to fund at instead. The presence of depositInstructions is the discriminator.
- Option 1
- Option 2
AutoPayout payload. Crypto recipients omit rail/ach/swift/instant/remittance; fiat (us|swift) recipients require rail and may carry the matching per-rail context block.
ISO 8601 timestamp
"2026-01-15T09:30:00.000Z"
client, auto ISO 8601 timestamp
"2026-01-15T09:30:00.000Z"
expired, client_cancelled insufficient_funds, provider_unavailable, provider_rejected, internal_error, cancelled Where to send funds to fund this order. Exactly one crypto_address block.
1 elementTransfers that funded this order, with how much of each it draws. Present on the order detail read for an order funded at a Conduit funding address; omitted on the list read and on an order that names its own source.