Skip to main content
A standing deposit address receives repeated deposits and converts them to one configured destination. The destination, slippage, and fee instruction is immutable. Eligible deposits become orders without /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 authenticated GET /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.
Response shape (200):
Returned addresses remain assigned even when a route is unavailable. Check supported funding routes before sending.
  • ref: 1 to 128 characters, partner-scoped, URL-encoded as one segment. Identical instructions replay; changes return 409 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 within slippageBps. 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.
Eligible Bitcoin deposits can receive a deposit-scoped 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:
Returns { 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

Use PATCH /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:
Send exactly one of 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).