Skip to main content
This is an enterprise-only feature. Please contact us to enable.

What We’re Building

A server-side payment flow built on Fireblocks Flow. Fireblocks Flow lets you accept a crypto payment from any supported chain, wallet, or exchange and have it settled in a specific token on a specific chain. This guide uses the Flow API directly. By the end of this guide you will be able to:
  • Create a flow from your backend, specifying the mode, amount, settlement, and destination
  • Walk through the full flow: attach source, get quote, sign, broadcast
  • Send withdrawals from your treasury or vault to end-user wallets (API only)
  • Poll or receive webhooks for settlement completion
  • Handle errors and edge cases
This guide uses raw HTTP calls, making it suitable for backend services, AI agents, cron jobs, or any language with fetch. For an overview of what Fireblocks Flow can do — funding sources, settlement currencies, compliance, and webhooks — see the Fireblocks Flow overview.

Prerequisites

  • A Dynamic environment with Fireblocks Flow enabled
  • An environment API token (dyn_...) with flow.write scope from Developer > API Tokens in the dashboard
  • A connected wallet that can sign transactions on the chains you support. If your app doesn’t already handle wallet connection, use the Dynamic JavaScript SDK to connect a wallet and sign
  • Node.js 18+ (or any runtime with fetch)

Base URL

Overview

The flow is a state machine with seven sequential steps. The same seven steps are used in payment, deposit, and withdrawal flows — only the mode, how the amount is interpreted, and who acts as source vs destination change between them. This guide walks through all three flows end-to-end:
Each mutation must be valid for the current state. Calling endpoints out of order returns 409.

Resume and retry by state

A flow ID represents one execution attempt. Before retrying a request or restoring an interrupted session, fetch the flow and choose the next action from its current executionState.
Do not replay the last mutation without checking state. For example, calling attach source after the flow reaches source_confirmed attempts the invalid transition source_confirmedsource_attached and returns 409. source_confirmed can still have an active settlement, so continue polling or processing webhooks until settlementState is completed or failed.
Jump to the flow that matches your use case:

Authentication

The session token is returned once when you attach a source (Step 2). Store it for the duration of the flow.
Do not send Authorization: Bearer on SDK endpoints. SDK endpoints (/sdk/{environmentId}/...) only accept X-Dynamic-Flow-Session-Token. Sending a Bearer header on them returns 401 Unauthorized. Only the flow creation endpoint (/server/{environmentId}/flow/{mode}) requires the Bearer token.

Choose Your Flow

This guide covers three use cases. The seven steps are the same in each — what changes is the mode you pass in Step 1, how the amount is interpreted, and which wallet is source vs destination. Pick the flow that matches your use case:
  • Payment flowmode: "payment". The receiver fixes the amount on each transaction (e.g., a $25 invoice). Use for invoices, e-commerce checkouts, or paid services.
  • Deposit flowmode: "deposit". The sender chooses how much to send (e.g., a $100 top-up). Use for funding flows, on-ramps, or open-ended deposits.
  • Withdrawal flowmode: "withdraw". Your platform fixes the payout amount and signs from a treasury or vault; the end user receives funds at an address you pass per flow. HTTP API only — not available through the JavaScript SDK.
Each flow below is self-contained and walks through all seven steps end-to-end (the withdrawal flow references the deposit flow for shared steps).

Shared concepts

These apply to all flows:
Security model: The API key (dyn_... with flow.write scope) is required only to create a flow. Creation is where amount, currency, destination, and settlement are fixed — so gating it behind the API key means a browser client has no endpoint that accepts those fields. Everything after creation is driven by a capability session token (dft_...) minted at source attachment.

Payment Flow

A complete walkthrough for mode: "payment", where the receiver fixes the amount the sender must pay.

Step 1 (Payment): Create a Flow

Create a flow from your backend. This is a server-side call authenticated by your API token with flow.write scope. The body specifies the amount, currency, settlement tokens, and destination wallets — these are fixed at creation time and cannot be changed later.
Response (201):
Store flow.id — this is your flowId for all subsequent steps. Pass it to your frontend to drive the rest of the flow.

Step 2 (Payment): Attach Source

Declare which wallet and chain the payer is paying from. This step returns a session token (dft_...) that authenticates all subsequent calls, and starts risk screening asynchronously.
For a Solana payer, use the Solana chain values and address format:
Response (200):
Store the sessionToken — it is returned once and authenticates all subsequent calls for this flow. Error (403): Blocked by sanctions screening — cancel and retry with a different source.

Step 3 (Payment): Get a Quote

Specify which token the sender is paying with. The API finds the best route to the flow’s settlement token(s) for the receiver’s requested amount.
Response (200):
In payment mode, toAmount matches the receiver’s requested amount and fromAmount is what the sender must pay (including swap costs and fees).
Quotes expire in 60 seconds. If it expires before you call /prepare, request a new quote. The quoteVersion increments with each new quote.
For same-chain, same-token payments (no swap needed), the API builds a direct transfer payload — no routing required.

Step 4 (Payment): Prepare Signing

Locks in the quote and returns the signing payload. You can optionally request on-chain balance assertions.
Response (200): Transaction with executionState: "signing" and quote.signingPayload:
The payload structure depends on the chain: Possible errors:
  • 422 — Quote expired: go back to Step 3
  • 422 — Risk not cleared: poll GET /flow/{flowId} until riskState is "cleared", then retry
  • 422 — Insufficient balance: response includes required and available amounts

Step 5 (Payment): Sign and Broadcast On-Chain

Use prepared.quote.signingPayload to sign and submit the transaction with whatever wallet your sender has connected. The payload — and the code to sign it — depends on the source chain. See Signing the transaction by chain for EVM, Solana, Sui, and Bitcoin examples. It returns a txHash you’ll report in Step 6.

Step 6 (Payment): Notify Backend of Broadcast

This endpoint does not broadcast the transaction on-chain. That already happened in Step 5 — when the wallet signed and submitted the transaction, the network received it. This call is your client notifying Dynamic’s backend that the broadcast happened and handing over the resulting txHash, so the backend can start watching the chain for confirmation and orchestrating settlement.
Report the transaction hash back to the API once your wallet returns it.
Response (200): Transaction with executionState: "broadcasted".
Point of no return. After this call, the transaction cannot be cancelled. The backend begins monitoring the blockchain and orchestrating settlement.

Step 7 (Payment): Wait for Settlement

After broadcast, the backend handles cross-chain settlement automatically. Monitor progress via polling or webhooks.

Option A: Polling

No authentication required. Poll every 3 seconds. Stop when you see a terminal state: Settlement progresses through: noneroutingbridgingswappingsettlingcompleted. Same-chain, same-token payments jump directly to completed. Set up a webhook to receive events as the transaction progresses:
Each event fires on every state transition for that axis. The payload tells you what changed:
Example: flow.settlement.updated payload
Key states to handle:
webhook-handler.ts

Deposit Flow

A complete walkthrough for mode: "deposit", where the sender chooses how much to send. The seven steps mirror the payment flow — what changes is the mode and how the amount is interpreted.

Step 1 (Deposit): Create a Flow

Create a deposit flow from your backend. The body specifies the deposit amount, settlement tokens, and destination wallets.
Response (201):
Store flow.id — this is your flowId for all subsequent steps. Pass it to your frontend to drive the rest of the flow.

Step 2 (Deposit): Attach Source

Declare which wallet and chain the depositor is funding from. This step returns a session token (dft_...) that authenticates all subsequent calls, and starts risk screening asynchronously.
For a Solana depositor, use the Solana chain values and address format:
Response (200):
Store the sessionToken — it is returned once and authenticates all subsequent calls for this flow. Error (403): Blocked by sanctions screening — cancel and retry with a different source.

Step 3 (Deposit): Get a Quote

Specify which token the depositor is funding with. The API finds the best route from that token to the flow’s settlement token(s) for the deposit amount.
Response (200):
fromAmount is what the depositor’s wallet will be charged in the source token; toAmount is what lands at the destination after swap and fees.
Quotes expire in 60 seconds. If it expires before you call /prepare, request a new quote. The quoteVersion increments with each new quote.
For same-chain, same-token deposits (no swap needed), the API builds a direct transfer payload — no routing required.

Step 4 (Deposit): Prepare Signing

Locks in the quote and returns the signing payload. You can optionally request on-chain balance assertions.
Response (200): Transaction with executionState: "signing" and quote.signingPayload:
The payload structure depends on the chain: Possible errors:
  • 422 — Quote expired: go back to Step 3
  • 422 — Risk not cleared: poll GET /flow/{flowId} until riskState is "cleared", then retry
  • 422 — Insufficient balance: response includes required and available amounts

Step 5 (Deposit): Sign and Broadcast On-Chain

Use prepared.quote.signingPayload to sign and submit the transaction with whatever wallet the depositor has connected. The payload — and the code to sign it — depends on the source chain. See Signing the transaction by chain for EVM, Solana, Sui, and Bitcoin examples. It returns a txHash you’ll report in Step 6.

Step 6 (Deposit): Notify Backend of Broadcast

This endpoint does not broadcast the transaction on-chain. That already happened in Step 5 — when the wallet signed and submitted the transaction, the network received it. This call is your client notifying Dynamic’s backend that the broadcast happened and handing over the resulting txHash, so the backend can start watching the chain for confirmation and orchestrating settlement.
Report the transaction hash back to the API once your wallet returns it.
Response (200): Transaction with executionState: "broadcasted".
Point of no return. After this call, the transaction cannot be cancelled. The backend begins monitoring the blockchain and orchestrating settlement.

Step 7 (Deposit): Wait for Settlement

After broadcast, the backend handles cross-chain settlement automatically. Monitor progress via polling or webhooks.

Option A: Polling

No authentication required. Poll every 3 seconds. Stop when you see a terminal state: Settlement progresses through: noneroutingbridgingswappingsettlingcompleted. Same-chain, same-token deposits jump directly to completed. Set up a webhook to receive events as the transaction progresses:
Each event fires on every state transition for that axis — check data.newState to decide what action to take. See the payment webhook section for the full payload shape. Key states to handle:
webhook-handler.ts

Deposit Address Flow

A deposit address flow generates a unique address per transaction. The user sends funds to that address directly — no wallet connection or on-chain signing is required on your end. The inbound transfer is detected automatically and the flow advances. Use this when your users are paying from a CEX, a cold wallet, or any context where connecting a Web3 wallet is not practical. The deposit address can also be rendered as a QR code for users to scan from a mobile wallet. Supported chains: BTC, SOL, EVM, and TRON.

How it differs from the wallet flow

Step 3 (Deposit address): Attach Source

Pass refundAddress to specify where to return funds if the transfer fails. Omit to refund to the original sender.
Response (200): Flow with executionState: "source_attached".

Step 4 (Deposit address): Get a Quote

Omit fromTokenAddress for native tokens (BTC, SOL, or EVM native). Response (200):
Show quote.depositAddress to the user. They send quote.fromAmount (in the token’s base unit) to that address from any wallet or exchange.

Step 5 (Deposit address): Wait for transfer detection

Steps 5–7 (prepare, sign, broadcast) do not exist for deposit address flows. Once the user sends funds, the transfer is detected automatically and the flow advances. Poll GET /sdk/{environmentId}/transactions/{transactionId} every few seconds until executionState leaves "quoted": Deposit addresses expire after 48 hours. If the flow reaches "failed" with no funds received, create a new transaction.

Withdrawal Flow

Withdrawals and money-out are supported through this HTTP API only. The Fireblocks Flow JavaScript SDK guide covers payment and deposit flows, not platform-to-user payouts.
A withdrawal sends funds from your treasury, vault, or server wallet to an end-user wallet, optionally converting across chains and tokens along the way. It uses the same seven steps as the other flows, with mode: "withdraw" and reversed roles: Each withdrawal flow specifies the end user’s destination directly in the flow creation body. See Money in and money out on the overview for the product model.
Your application must sign Steps 4–5 with a wallet you control (Fireblocks vault, server wallet, or similar). End users do not sign withdrawal transactions in their browser the way they do for deposits.

Step 1 (Withdrawal): Create a Flow

Create a withdrawal flow from your backend with the payout amount and the end user’s destination wallet.
Response (201): Same shape as the deposit flow Step 1. Store flow.id as your flowId.

Step 2 (Withdrawal): Attach Source

Attach your treasury, vault, or server wallet as the funding source — not the end user’s wallet.
Use the chain and token your treasury holds (e.g., USDC on Base). The quote step routes from this source to the settlement token and destination you set in Step 1. Response (200): Returns the session token and flow with executionState: "source_attached". Store the sessionToken — it authenticates all subsequent calls. Error (403): Blocked by sanctions screening — cancel and retry with a different source.

Steps 3–7 (Withdrawal): Quote Through Settlement

Steps 3–7 use the same endpoints as the deposit flow. Differences are who signs and what you do on completion: Example — Step 3 quote (treasury pays with USDC on Base; user receives USDC on Ethereum):
On completion, settlementState === "completed" means funds reached the destination from Step 1. Handle flow.settlement.updated webhooks (where data.newState === "completed") the same way as in Step 7 (Deposit), but credit the user’s balance or close the withdrawal request instead of treating it as an inbound deposit.

Signing the Transaction by Chain

Step 5 of every flow signs and broadcasts prepared.quote.signingPayload, then reports the resulting txHash in Step 6. The flow itself is identical across chains — only this signing step differs. The payload field depends on the source chain:
Any Dynamic SDK can be used for signing — not just the browser JS SDK. React, React Native, Flutter, Swift, Kotlin, Unity, and the Node.js SDK (server-side MPC wallets) all surface the same signing primitives. See docs.dynamic.xyz for platform-specific guides. The examples below show browser wallet (viem/wagmi) and Node SDK patterns.
In each example, prepared is the response from Step 4.

EVM

Uses an already-connected EVM wallet client (walletClient) — for example the one returned by useWalletClient() in wagmi or by Dynamic’s primary wallet connector. If evmApproval is present, send the approval transaction first, then the main one.
sign-evm.ts

EVM — Node SDK (server-side MPC wallet)

sign-evm-node.ts

Solana

serializedTransaction is a base64-encoded versioned transaction — there are no approvals. Deserialize it, sign with your connected wallet (or keypair), and broadcast. The example below uses @solana/web3.js.
sign-solana.ts
signTransaction returns the signature only, not the full signed transaction. The Node SDK’s DynamicSvmWalletClient.signTransaction returns the raw Ed25519 signature as a base58 string (88 chars / 64 bytes) — NOT a re-serialized transaction. You must decode it and add it back to the transaction before broadcasting.

Solana — Node SDK (server-side MPC wallet)

sign-sol-node.ts
Solana routing and oracle errors. The default cheapest route for SOL→USDC may use the Titan protocol, which requires fresh Pyth oracle data embedded in the transaction. If you see PythOracleOutdated errors, pass slippage: 0.5 (or higher) in Step 4’s quote request to route via dflow instead. Alternatively, settle cross-chain to Base (SOL → USDC on Base via MayanFinance) which has no oracle dependency.

Sui

Sui returns the same serializedTransaction field as Solana — a base64-encoded transaction. Deserialize and sign it with your Sui keypair via @mysten/sui, then report the resulting digest as txHash.

Bitcoin

Bitcoin returns a psbt field — a base64-encoded unsigned PSBT. Sign each input with your wallet, finalize, extract the raw transaction, broadcast it, and report the resulting txid as txHash.

Cancelling a Transaction

Cancel any time before broadcast (states: initiated, source_attached, quoted, signing):
Returns the transaction with executionState: "cancelled". Once cancelled, create a new transaction to retry.

Fee Collection and Claiming

Charge your own fee on every swap a flow runs. You attach a fee config when you create a flow, and on each swap a percentage of the source amount is collected and delivered to the recipient wallet(s) you specify. This is direct revenue for your business, layered on top of Dynamic’s own routing costs. Depending on the route used to fill a swap, fees are collected one of two ways:
  • Distributed on-chain at swap time — the fee is sent straight to the wallet address you specified in the fee configs when creating the flow, as part of the settlement transaction. Nothing to claim; it arrives with the swap.
  • Accrued as a claimable balance — the fee accumulates off-chain (typically as USDC) and you sweep it later with the claim flow below.
Because either can happen, poll the balances endpoint and run the claim flow to collect anything that accrued rather than being distributed directly.
Fee collection is an EVM-only feature. See Supported chains for fees.

Add a fee config

feeConfig is an optional field on the create flow body (Step 1 of any mode — payment, deposit, or withdrawal). It is fixed at creation and cannot be changed later.
Validation. The create call returns 422 if:
  • there are fewer than 1 or more than 10 recipients,
  • any percentage is not strictly between 0 and 1,
  • the recipients’ combined percentage is 1 or greater (that would consume the entire swap), or
  • any walletAddress is not a valid EVM address (see Supported chains for fees).
With multiple recipients, each recipient’s share is percentage × sourceAmount, split independently — so [{ 0.01 }, { 0.005 }] collects 1.5% total and delivers each recipient their own cut.

Supported chains for fees

Fee collection is an EVM-only feature:
  • Recipient addresses must be EVM (0x…). A non-EVM recipient (for example a Solana address) is rejected at flow creation with 422. Both underlying settlement models require an EVM recipient — on-chain distribution sends to an EVM receiver, and claimable balances are released by an EVM signature from the recipient wallet.
  • Fees are collected on EVM swaps and any claimable balance settles on an EVM chain, denominated per token and chain in the balances response.
The source token a payer swaps from can still be on any supported chain; the fee itself is always collected to, and claimed from, an EVM address.

Check claimable balances

Check whether a recipient has any fees waiting to be claimed. Returns a per-token, per-chain breakdown plus a hasClaimableFees convenience flag.
Response (200):
An empty balances list (hasClaimableFees: false) means there is nothing to claim right now — either no fees have accrued, or every fee was distributed directly on-chain at swap time.
Error (400): recipientAddress is not a valid EVM address.

Claim accrued fees

Claiming is a two-step, sign-in-the-middle flow: initiate to get the payload(s) the recipient must sign, then submit the signatures. The recipient wallet authorizes the release — no provider details are ever exposed. 1. Initiate the claim.
Response (200):
An empty steps array means there was nothing to claim — no signing or submit needed. Error (400): recipientAddress is not a valid EVM address. 2. Sign each step with the recipient wallet, then submit the signatures.
Response (200):
After a successful submit, re-check balances — the claimed balance should now be empty.

Example: claim in TypeScript

claim-fees.ts
Sign data.message exactly as returned — don’t reconstruct or modify it. data.signatureKind (eip191) tells you how to sign: it’s a standard personal-sign message, so most libraries’ signMessage (for example viem’s) produce the right signature directly.

Complete Example

A self-contained TypeScript script that creates a flow from the backend, executes the payment lifecycle, and polls for settlement. It assumes you already have a connected wallet client — for example one returned by Dynamic’s JS SDK, wagmi’s useWalletClient(), or any viem WalletClient. If your app doesn’t have wallet connection yet, use the Dynamic JavaScript SDK to provide it.
This example pays from an EVM wallet. To pay from Solana, keep Steps 1–4 and 6–7 identical — only swap the Step 5 signing block for the Solana variant (sign-solana.ts), attach a Solana source (fromChainName: "SOL", fromChainId: "101"), and quote with a Solana fromTokenAddress (mint, or 11111111111111111111111111111111 for native SOL).
flow-example.ts

Supported Chains and Native Tokens

Fireblocks Flow supports the following chains. Use these values for chainName, chainId, and token addresses in your settlement config and source attachment.

Chain Reference

Except for the EVM chains listed below, only mainnet is supported:

Native Token Addresses

For native tokens (ETH, SOL, BTC, SUI, TRX), use any of the accepted addresses below in token address fields: For non-native tokens, use the token’s contract address on that chain (e.g., 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 for USDC on Base).

Error Reference

By status code

By step

Quote failure response format:When no quotes are available, the 422 response includes a quoteFailures array with per-settlement failure details:
Each entry tells you which settlement token failed (symbol on chainName/chainId) and why (reason).Quote failure reasons:

Tips

  • Balance assertions: Enable both assertBalanceForGasCost and assertBalanceForTransferAmount in prepare to catch insufficient balance before signing.
  • Quote evaluation: Check quote.fees.totalFeeUsd and quote.estimatedTimeSec programmatically before proceeding. Cancel and retry with a different token/chain if fees are too high.
  • Quote expiry: Quotes last 60 seconds. Sign promptly. You can re-quote multiple times — quoteVersion increments with each new quote.
  • Idempotency: Use the memo field to store your own idempotency keys (e.g., { "orderId": "order_abc123" }).
  • Error recovery: If your process crashes mid-flow, call GET /flow/{flowId} to check the current executionState and resume from the correct step.
  • Session token lifetime: Matches the flow’s expiresIn (default 1 hour).
  • Balance API — required params: Pass includeNative=true to include ETH/SOL in the response (omitted by default). For Solana, networkId=101 is also required — without it the endpoint returns [] even for funded wallets. For EVM, use the chain ID (e.g. networkId=8453 for Base). The indexer can lag 60–90 seconds after a deposit; if a balance check returns empty immediately after funding, wait a moment and retry.
  • Solana routing: SOL→USDC routes vary by market conditions. The Titan protocol (Pyth oracle–dependent) is common and usually works, but can fail with PythOracleOutdated if oracle prices are stale. If you hit this, try adjusting slippage (e.g. 0.5) to get an alternative route such as dflow. For agents, cross-chain settlement to Base (SOL → USDC on Base via MayanFinance FastMCTP) avoids oracle dependencies entirely and has zero bridge fees.
  • Solana simulation: Pre-built Solana transactions from the flow API may fail RPC simulation with oracle errors even though they succeed on validators. Use skipPreflight: true when calling sendRawTransaction to bypass simulation.

Quick Reference

Last modified on July 15, 2026