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 Deadline for execution to begin, not merely for the source to be funded. If execution hasn't been claimed by this time, the order transitions to status: cancelled with cancellationReason: 'expired' and can no longer execute — funding the source after this timestamp does not revive it. Create a new order to get a fresh rate lock.
"2026-01-15T09:30:00.000Z"
ISO 8601 timestamp
"2026-01-15T09:30:00.000Z"
Echoes the create-time value. When true, Conduit automatically claims execution once the available source balance covers totalDebit (principal plus fees), with no client action required — orders sharing the same source resource execute oldest-first, so a still-underfunded older order can delay a newer, already-funded one; when false, the client must call POST /v2/orders/{id}/execute (repeatable after funding if a prior attempt returned 422 INSUFFICIENT_FUNDS). Order creation never checks or reserves the source's available balance regardless of this value.
^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.
Present on an order that declared a margin which comes to at least one minor unit of the source asset. assetAmount is the total accrued to you, fixed at quote time. The two shapes reach the customer differently: the markupBps part is folded into the quoted rate, so it never appears in fees[] and does not move totalDebit, while the markupAmount part is a line item in fees[] owned by you and it does move totalDebit.
ISO 8601 timestamp
"2026-01-15T09:30:00.000Z"
Which path claimed execution: 'client' for a POST /v2/orders/{id}/execute call, 'auto' for automatic execution by Conduit. Set as soon as execution is claimed — well before the order reaches a terminal status — so it can appear on an order that is still status: pending while its conversion is in flight. Absent on an order that hasn't started executing yet (including one cancelled before execution began).
client, auto ISO 8601 timestamp
"2026-01-15T09:30:00.000Z"
expired, client_cancelled insufficient_funds, provider_unavailable, provider_rejected, internal_error, cancelled Present when this order redeemed a POST /v2/quotes option — the id of the option it consumed.
^qop_[0-9A-Za-z]{22}$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.