/quote or /submit.
Prerequisites
- An Orchestra account. Create one in the dashboard. Flashnet reviews new accounts before enabling API access.
- A server key (
fn_...) from API keys in the dashboard. Keep it on your backend. For browsers and apps, use a scoped client key (fnp_...); see Authentication.
Create
Select a destination from authenticatedGET /v1/standing-deposit-addresses/destinations, which returns { destinations: [{ chain, asset }] }. Each pair is eligible through at least one configured source, not every returned address. Availability can change; Hedera is excluded.
Create or fetch the instruction under your customer reference:
Replace
SERVER_KEY with your fn_... key. Use a new X-Idempotency-Key for each operation and reuse it when retrying that same request. Amounts are integer strings in the asset’s smallest unit: "100000" is 0.001 BTC; "50000000" is 50 USDC on Base. Read each asset’s decimals from /routes.200):
ref: 1 to 128 characters, partner-scoped, URL-encoded as one segment. Identical instructions replay; changes return409 instruction_conflict.slippageBps: 0..10000, default 50.feeBps: floor of 0..9999, default 0.affiliateIds: up to 16, frozen at creation; overrides 1..9999, total below 10000.refundAddresses: source-chain targets for generated-order refunds, not automatic dust refunds.- Reads require a server key; mutations also require
X-Idempotency-Key.GET /{ref}returns the shape above, without the instruction. Store references, recipient, and fee configuration yourself; there is no list endpoint.
Deposits
Orchestra verifies deposits and senders, applies confirmation policy, and quotes eligible funds at the live rate withinslippageBps. Route and partner policy can hold execution.
Funding rules:
- A deposit in the destination asset itself (Base USDC into a Base USDC destination) is held with code
standing_identity_pair. - An address for one EVM chain does not authorize the same string on another chain. Fund only the chain the key names.
- Tron standing funding supports USDT only.
- EVM and Solana dust below the route minimum is held and can batch with later deposits of the same asset to the same address into one order. Bitcoin outputs are independent; each must cover the claim fee plus the route minimum.
zeroconfOffer. Standing offers require explicit consent, even for allowlisted partners. Without acceptance, processing waits for confirmation. See ZeroConf for the distinct offer shape and decision endpoints.
List deposits newest first:
{ deposits, nextOffset }. Read status and code for progress or the reason funds are held. orderId and quoteId link the generated order. The OpenAPI document defines the StandingDeposit response schema.
Pause and refund
UsePATCH /v1/standing-deposit-addresses/{ref} with { "enabled": false } to pause or { "enabled": true } to resume. Other fields return 400 immutable_instruction; there is no delete.
Pause blocks new source commitments, including outstanding batches, while observation continues. Already signed transactions retain their recovery path. Resume retries pause holds, not requested refunds or unrelated review holds. Disabled routes are retryable; restoring policy does not clear every hold. Nothing is refunded automatically.
Request a refund for held deposits:
depositIds (1 to 200, same address and asset; Bitcoin exactly one) or batchId, plus a source-chain refundAddress. 202 { batchId, status: "refund_requested" } confirms enqueueing, not broadcast. Ineligible deposits return 409 refund_not_available.
The worker checks custody and screening; existing orders use order-refund processing. Bitcoin refunds wait for 6 confirmations and deduct network fees. Unconverted Tron deposits require an operator and remain reserved under standing_tron_refund_requires_operator.
Accumulation and liquidation addresses are the previous model; see Reusable addresses (legacy).