Prerequisites:
Protocol-Specific Approach
Use this when you want to work with a specific yield protocol. Request Transaction Data Fetch specific protocol information using:
Pick the section that matches where the user wants to receive the withdrawn funds. Each shows the extra parameters, an example request, and the response you get back.
Simple withdraw
Withdraw to the strategy’s underlying token on the strategy’s own chain — no bridge. Only the required parameters above are needed, andcrossChain.isCrossChain stays false.
For supported ERC-4626 strategies, add withdrawAll=true when the user intends to redeem the wallet’s complete vault-share balance. Continue sending amount as the expected underlying amount; partial withdrawals must omit withdrawAll and remain asset-denominated.
Example Request:
Same-chain swap withdraw
Want to receive a different token on the strategy’s own chain? PasstoTokenAddress (with a toChainId/chainIdOut matching the strategy chain) to swap the withdrawn underlying into that token. The response appends the swap transaction(s) after the withdraw bytecode, and crossChain.isCrossChain stays false.
Additional Parameters:
When
toTokenAddress is provided with a toChainId matching the strategy
chain, the API automatically appends a same-chain swap from the strategy’s
underlying asset to toTokenAddress after the withdraw. The amount parameter
refers to the underlying amount withdrawn (before the swap), and
crossChain.isCrossChain remains false.toTokenAddress to swap after withdrawing:
Unlike a bridge quote, a same-chain swap quote has
fromChainId === toChainId
(both the strategy chain), and crossChain.isCrossChain stays false — no
cross-chain tracking is needed.Cross-chain swap withdraw
Want the funds on another chain? Pass atoChainId/chainIdOut (with a toTokenAddress) that differs from the strategy’s chain. The response adds a quote object describing the bridge selection, the resolved tokens, and the expected/minimum output amount, and sets crossChain.isCrossChain to true.
Additional Parameters:
Example Request:
The top-level
id is used for execution tracking — store it and pass it to GET /actions/:id to track the cross-chain withdrawal through completion (see Checking Cross-Chain Withdrawal Status below).The quote object describes which bridge was selected (bridge), the expected outputAmount, and the worst-case minimumOutputAmount (slippage floor). Display these to the user before they sign.Output format options
By default the endpoint returns rawbytecode. These optional parameters change the response format and apply to either withdraw type above.
Example Request (Fireblocks output):
If you are using Fireblocks custody, set
output=fireblocks and pass your vault accountId. The wallet parameter must be a smart wallet previously provisioned via POST /fireblocks-smart-account (see Fireblocks Integration).
transactionData.transactionRequest payload can be submitted directly to the Fireblocks Transactions API (POST /v1/transactions) — no further encoding required. The Earn Owner vault must be configured as the signer (see Fireblocks Integration). After the withdrawal completes, transfer funds out of the smart wallet to your Omnibus wallet or any other destination.
Use
GET /strategies to list available protocols, then pass the chosen
strategy ID into the protocol-specific approach above.Executing the Transaction
Checking Cross-Chain Withdrawal Status
Cross-chain withdrawals are asynchronous: the source-chain withdraw + bridge transaction is signed first, then the bridged funds are delivered on the destination chain. To track progress to completion, use theid returned in the bytecode response:
Example Request:
Poll this endpoint until
status reaches a terminal value (SUCCESS, FAILED, REFUNDED, or EXPIRED). The transactions array lists each on-chain hash as it is confirmed.
Same-chain withdrawals do not need this polling — the withdraw completes
inline with the user’s signed transaction. The
id is still returned for
record-keeping and can be queried the same way.Webhook Notifications
As an alternative to polling, Pods can push every status transition to a URL you control. The payload is identical toGET /actions/:id, so you can drive the same UI off either source.
Default webhook URL configuration is currently provisioned manually — contact the Pods team to register your default
webhookURL (and any optional custom headers, e.g. an HMAC signature header). For a single withdrawal request, pass webhookURL on the bytecode endpoint to override the customer-level default. Self-service configuration via the admin panel is coming soon.
Body shape:
SUCCESS):
- A request fires for every status change, so you may receive multiple deliveries per withdrawal (
INITIAL→PENDING→SUCCESS). - Pods expects a
2xxresponse. Non-2xxresponses are recorded but not automatically retried; reconcile withGET /actions/:idif you need at-least-once guarantees. - Respond as quickly as possible; do the heavy work asynchronously on your side.
Next Steps
Check Positions
View your remaining positions
New Deposit
Make a new deposit
Protocol Info
Check protocol information