Skip to main content
In this section, you’ll learn how to request ready-to-use transaction data (bytecode) for withdrawing from a yield position.

Protocol-Specific Approach

Use this when you want to work with a specific yield protocol. Request Transaction Data Fetch specific protocol information using:
Required Parameters: Optional Parameters (cross-chain): Optional Parameters (response format): Example Request:
Example Request (cross-chain withdraw):
Example Response (same-chain withdraw):
Example Response (cross-chain withdraw): When toChainId differs from the strategy’s chain, the response also includes a quote object describing the bridge selection, the resolved tokens, and the expected/minimum output amount. The crossChain.isCrossChain flag is true.
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.
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).
Example Response:
The 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

Batch all bytecode legs on the same chainId into one atomic transaction. See Executing Bytecode.
Make sure you have sufficient balance in your position before attempting to withdraw. Check your open positions first using the check positions endpoint.

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 the id returned in the bytecode response:
Path Parameters: Example Request:
Example Response (withdrawal in flight):
Status values: 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 to GET /actions/:id, so you can drive the same UI off either source.
Webhook URL configuration is currently provisioned manually — contact the Pods team to register your webhookURL (and any optional custom headers, e.g. an HMAC signature header). Self-service configuration via the admin panel is coming soon.
Transport: Body shape:
Example payload (cross-chain withdrawal reaching SUCCESS):
Delivery semantics:
  • A request fires for every status change, so you may receive multiple deliveries per withdrawal (INITIALPENDINGSUCCESS).
  • Pods expects a 2xx response. Non-2xx responses are recorded but not automatically retried; reconcile with GET /actions/:id if 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