> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flashnet.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Deposit addresses

> Repeated deposits, fixed destination

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](https://orchestra.flashnet.xyz/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](/api/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:

<CodeGroup>
  ```bash curl theme={null}
  curl -X PUT https://orchestration.flashnet.xyz/v1/standing-deposit-addresses/customer-4821 \
    -H "Authorization: Bearer SERVER_KEY" \
    -H "X-Idempotency-Key: $(uuidgen)" \
    -H "Content-Type: application/json" \
    -d '{
      "destination": { "chain": "spark", "asset": "USDB", "address": "RECIPIENT_ADDRESS" },
      "slippageBps": 50,
      "feeBps": 25,
      "affiliateIds": ["acme-wallet"],
      "refundAddresses": { "base": "0xYourBaseRefundAddress", "solana": "YourSolanaRefundAddress" }
    }'
  ```

  ```typescript TypeScript theme={null}
  const ref = encodeURIComponent("customer-4821");
  const res = await fetch(`https://orchestration.flashnet.xyz/v1/standing-deposit-addresses/${ref}`, {
    method: "PUT",
    headers: {
      Authorization: "Bearer SERVER_KEY",
      "X-Idempotency-Key": crypto.randomUUID(),
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      destination: { chain: "spark", asset: "USDB", address: "RECIPIENT_ADDRESS" },
      slippageBps: 50,
      feeBps: 25,
      affiliateIds: ["acme-wallet"],
      refundAddresses: { base: "0xYourBaseRefundAddress", solana: "YourSolanaRefundAddress" },
    }),
  });
  const standing = await res.json();
  ```
</CodeGroup>

<Info>
  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`.
</Info>

Response shape (`200`):

```text theme={null}
{
  standingAddressId,
  addresses: { [sourceChain]: address },
  enabled
}
```

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](/orchestra/zeroconf#standing-deposits) for the distinct offer shape and decision endpoints.

List deposits newest first:

```bash theme={null}
curl "https://orchestration.flashnet.xyz/v1/standing-deposit-addresses/customer-4821/deposits?limit=50&offset=0" \
  -H "Authorization: Bearer SERVER_KEY"
```

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](https://orchestration.flashnet.xyz/openapi.json) 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:

```bash theme={null}
curl -X POST https://orchestration.flashnet.xyz/v1/standing-deposit-addresses/customer-4821/resolve \
  -H "Authorization: Bearer SERVER_KEY" \
  -H "X-Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{ "depositIds": ["dep_..."], "refundAddress": "0xYourBaseRefundAddress" }'
```

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)](/orchestra/legacy/reusable-addresses).