Prerequisites: Make sure you’ve reviewed how to check protocol
info first.
Protocol-Specific Approach
Use this when you want to work with a specific yield protocol. Request Transaction Data Fetch specific protocol information using:
Optional Parameters (same-chain swap):
When
fromTokenAddress is provided with a fromChainId matching the strategy
chain, the API automatically prepends a same-chain swap from
fromTokenAddress to the strategy’s underlying asset. The amount parameter
refers to the amount of fromTokenAddress to swap, and
crossChain.isCrossChain remains false.
Optional Parameters (response format):
Example Request (direct deposit):
fromTokenAddress to swap first:
fromChainId 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 deposit through completion (see Checking Cross-Chain Deposit 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=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).
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 Deposit Status
Cross-chain deposits are asynchronous: the source-chain bridge transaction is signed first, then the bridged funds are delivered and deposited 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, so you can surface progress to the user as the bridge and the destination-chain deposit complete in sequence.
Same-chain deposits do not need this polling — the deposit 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.
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.
Body shape:
SUCCESS):
- A request fires for every status change, so you may receive multiple deliveries per deposit (
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
Monitor your open yield positions
Withdraw
Learn how to withdraw from positions