The core challenge of integrating the OKX DeFi API for deposits and withdrawals is not making the API calls, but understanding that it returns not a single transaction, but a series of calldata to be executed in order. The dataList returned by /api/v6/defi/transaction/enter may contain an APPROVE step first, followed by a DEPOSIT step. You must sign and broadcast each one sequentially. Skipping steps or executing them out of order will lead to on-chain failure. Position queries use a different set of endpoints. /api/v6/defi/user/asset/platform/list first gets the list of protocols and their analysisPlatformId, and then a detail endpoint is used to view specific positions. The starting point for risk verification is your own code: the OKX API agreement explicitly states that the platform only provides "connection and execution" and does not provide investment advice. Position limits and risk control measures need to be implemented by you at the application layer.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
Deposits: You Get a Set of Calldata, Not a Single Transaction
When calling POST /api/v6/defi/transaction/enter, the required fields are investmentId, address, and userInputList. In userInputList, you need to pass the token contract address, chainIndex, and coinAmount (a human-readable amount like "0.2", not wei). investmentId is obtained from the investment product query endpoint; do not construct it yourself.
The returned dataList is a list of execution steps. callDataType distinguishes the operation type (approve, deposit, withdraw, claim, etc.), and you need to sign and broadcast each one in order. In the Ethereum ecosystem, the typical flow is to first authorize the ERC-20 token, then execute the deposit contract call. If you only sign the DEPOSIT step and skip APPROVE, the transaction will revert on-chain due to insufficient allowance. After broadcasting, the TxIDs you receive must be checked one by one. Do not assume the entire process is complete just because the last step succeeded.
For V3 Pool type investment products (like PancakeSwap V3), you also need to pass tickLower and tickUpper when creating a new position. When adding liquidity to an existing position, you must pass tokenId. The slippage parameter defaults to "0.01" (1%) and is only effective for adapter/Zap routes. If your scenario involves a DEX pool, the slippage setting directly affects the execution result. Whether the default value is appropriate depends on the liquidity of the trading pair.
Withdrawals: Same Request Model, Different Field Meanings
Withdrawals use the same /api/v6/defi/transaction/enter endpoint. The official documentation states that enter and exit share a request model, and some fields are only valid for specific operations. In practice, investmentId and address are still required, but the meaning of userInputList changes from "tokens to invest" to "position information to retrieve". For V3 Pool withdrawals, tokenId is required.
The dataList returned for a withdrawal may contain multiple steps, such as unstake, then withdraw, and finally claim rewards. As with deposits, sign and broadcast each step sequentially. Do not assume that a single step can complete the entire withdrawal. If the withdrawal involves repaying a loan (like Aave lending protocols), you also need to confirm there is no outstanding debt, otherwise the withdraw may fail due to insufficient health factor.
Claiming rewards is a separate endpoint, POST /api/v6/defi/transaction/claim. rewardType distinguishes the reward type: REWARD_INVESTMENT (investment product mining rewards, most common), REWARD_PLATFORM (protocol rewards, requires analysisPlatformId), V3_FEE (requires tokenId), UNLOCKED_PRINCIPAL (matured principal, requires principalIndex). Do not mix claim operations into the withdrawal flow to do everything at once. Handling them separately makes it easier to troubleshoot issues.
Positions: First Query the Protocol List, Then Details
POST /api/v6/defi/user/asset/platform/list takes walletAddressList (each wallet corresponds to a chain) and returns an overview of that address's positions across various DeFi protocols: protocol name, total asset value in USD, number of investment products, and analysisPlatformId. The assetStatus field in the response is worth noting: 1 means updated, 2 means updating. If it is 2, the returned data may not be the latest state, and you may need to wait or query again.
After getting the analysisPlatformId, call the detail endpoint to see specific positions. The details distinguish between assetsTokenList (asset tokens), borrowTokenList (borrowed tokens, in LSDFi scenarios), rewardDefiTokenInfo (compounded rewards), unclaimedFeesDefiTokenInfo (Uni V3 fees), etc. totalValue is denominated in USD and depends on price sources; do not treat it as an exact on-chain balance. When aggregating positions across protocols and chains, the updateAt timestamps from different protocols may be inconsistent. You need to understand this when looking at aggregated numbers.
Risk Verification: The Part the Platform Does Not Do For You
The OKX API agreement is very direct: the platform only provides services for connecting data and executing orders, and does not provide investment advice, trade recommendations, or portfolio management. This means the following judgments must be made in your own application layer:
Contract risk of the investment product itself. The API aggregates dozens of DeFi protocols, but the smart contract security, audit status, and historical events of each protocol are not in the API's returned fields. investmentId helps you locate the product, but it cannot tell you if the pool is trustworthy.
Health factor monitoring for borrowing scenarios. If you use the enter endpoint to execute a borrow operation (like Aave V3 Borrow), the API will not proactively push health factor alerts. You need to poll the healthRate field in the position details yourself (returned in LSDFi scenarios), or set thresholds at the application layer to trigger alerts or automatic repayment.
Slippage and routing risk. The default 1% slippage is a generic value, not the optimal value for the asset you are trading. In low-liquidity pools, 1% might not be enough, while during high volatility, it might be too wide, leading to MEV exploitation. This parameter needs to be adjusted based on the actual trading pair; the API will not make this judgment for you.
One actionable verification step: before broadcasting any transaction in the dataList, run it through eth_call or an on-chain simulation tool to confirm it will not revert. This can catch issues like insufficient allowance, insufficient balance, low health factor, or slippage exceeded, preventing you from paying gas for a failed transaction. After signing and broadcasting, the on-chain status of the TxID (success/reverted) is the final acceptance criterion. The dataList returned by the API is just a set of instructions to be executed, not the execution result itself.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
References
- OKX Wallet · Deposit (DeFi API Transaction Execution), accessed: 2026-10-22
- OKX Wallet · User Position Overview (DeFi API), accessed: 2026-10-22
- OKX Wallet · Holdings Detail (DeFi API), accessed: 2026-10-22
- OKX · OKX API Agreement (Liability and Limitation Clauses), accessed: 2026-10-22
- OKX Wallet · Claim DeFi Protocol Rewards (DeFi API), accessed: 2026-10-22
- OKX Wallet · DeFi API Introduction, accessed: 2026-10-22
- OKX Wallet · Investment Product Query (DeFi API), accessed: 2026-10-22
