A 1:1 mapping from DeBank Cloud API endpoints to Zerion API, covering token balances, net worth, DeFi positions, and history, with side-by-side code samples.
If you’ve been calling DeBank’s Cloud API for token balances, net worth, DeFi portfolios, or wallet history, the same data is available on Zerion API across 60+ EVM chains and Solana, often in a single call and with USD values precomputed.This guide shows the direct mapping for the main DeBank user endpoints, with copy-pasteable code for each.What you get with Zerion:
One call for tokens + DeFi: Collapse DeBank’s all_token_list and all_complex_protocol_list into a single /positions/?filter[positions]=no_filter response.
Solana on the same endpoints: DeBank is EVM-only. Pass any EVM or Solana address to /wallets/{address}/... and get back the same enriched shape.
Values precomputed: Zerion returns value (USD) per position and a portfolio breakdown by chain and by type (wallet, deposited, borrowed, locked, staked), so you don’t multiply amount by price yourself.
Prefer not to write code? The Zerion CLI wraps the same endpoints with a one-shot npx @zerion/cli init flow, useful for quick experiments and AI agents.
DeBank returns a flat array of token objects, where each token carries amount and price but no precomputed USD value (you multiply the two yourself). Zerion returns a JSON:API collection where each token is one entry under data[], with attributes.fungible_info for metadata and attributes.value for the USD value already computed. The same endpoint accepts both EVM and Solana addresses.
No direct equivalent. updated_at (ISO 8601) reflects last balance update.
DeBank’s token id for native gas tokens is the chain short name (for example eth, matic), not a contract address. Zerion returns null for the native token’s implementation address. If you key tokens by their DeBank id, remap native tokens before comparing.
DeBank’s total_balance returns total_usd_value plus a per-chain breakdown. Zerion’s /portfolio returns the total, the 24h change, a breakdown by chain, and a breakdown by position type (wallet, deposited, borrowed, locked, staked) in one response.
DeBank’s all_complex_protocol_list returns protocols, each with a nested portfolio_item_list[] of positions split into supply_token_list, borrow_token_list, and reward_token_list. Zerion flattens this: each position is one row under /positions/?filter[positions]=only_complex, tagged with protocol, protocol_module, and position_type (including loan for borrowed assets).
Sum value per position_type; net worth split is in /portfolio → positions_distribution_by_type
chain
relationships.chain.data.id
Borrowed-position exposure: DeBank surfaces debt via borrow_token_list and stats.debt_usd_value. In Zerion, borrowed assets come back as positions with position_type: loan, and the wallet-level debt total is positions_distribution_by_type.borrowed on /portfolio.
DeBank’s history_list (per chain) and all_history_list (across chains) return transactions with sends[], receives[], and a token_approve block, where token references point into a separate token_dict. Zerion’s /transactions/ returns enriched, human-readable transactions with the token metadata inlined in each transfer, plus the dApp when Zerion recognizes it. The same endpoint accepts both EVM and Solana addresses.
const API_KEY = process.env.ZERION_API_KEY;const address = "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045";const headers = { accept: "application/json", authorization: `Basic ${btoa(API_KEY + ":")}`,};const res = await fetch( `https://api.zerion.io/v1/wallets/${address}/transactions/?currency=usd&page[size]=20`, { headers });const { data } = await res.json();for (const tx of data) { const { operation_type, mined_at, transfers, fee } = tx.attributes; const chain = tx.relationships.chain.data.id; const dappId = tx.relationships.dapp?.data?.id; console.log(`[${mined_at}] ${operation_type} on ${chain}`); if (dappId) console.log(` via ${dappId}`); for (const t of transfers) { const sign = t.direction === "out" ? "-" : "+"; const symbol = t.fungible_info?.symbol ?? "NFT"; console.log(` ${sign}${t.quantity.float} ${symbol} ($${t.value?.toFixed(2) ?? "?"})`); } console.log(` Fee: $${fee.value?.toFixed(2) ?? "?"}`);}
DeBank’s all_nft_list returns NFTs across chains. The Zerion equivalent is /v1/wallets/{address}/nft-positions/, which returns each holding with collection metadata and floor-price-based valuation.
DeBank’s Cloud API is request/response, so keeping a wallet fresh means polling. Zerion offers transaction webhooks: subscribe a callback URL to one or more wallets and receive a POST when any of them transact.See the wallet activity alerts recipe for a working example.
Most DeBank use cases have a direct Zerion equivalent. A few aren’t covered, and others behave differently. Worth a scan before you cut over.Not supported today:
Protocol- and pool-level data: DeBank exposes protocol TVL, pool stats, and token-level analytics through its /v1/protocol, /v1/pool, and /v1/token endpoints. Zerion is wallet-centric and does not expose protocol or pool aggregates.
Long-tail chains: DeBank indexes some chains Zerion doesn’t yet cover. Check the supported chains list for the ones you rely on before migrating.
CEX labeling in history: DeBank tags known centralized-exchange deposit addresses via cex_dict. Zerion does not label CEX addresses.
Token first-seen timestamp: DeBank’s time_at (when a token first appeared) has no per-position equivalent; Zerion’s updated_at reflects the last balance change, not first acquisition.
If any of these matter for your migration, let us know. Your feedback helps shape our roadmap.Worth knowing:
Solana: DeBank is EVM-only. Zerion accepts Solana addresses on the same /wallets/{address}/... endpoints used for EVM, and returns the same enriched shape. DeFi positions are not yet supported for Solana.
Chain IDs: DeBank uses lowercase short names (eth, bsc, matic, arb, op, avax). Zerion uses full string IDs (ethereum, binance-smart-chain, polygon, arbitrum, optimism, avalanche). See the full list.
Token IDs: DeBank keys tokens by contract address (and the chain short name for native tokens). Zerion uses its own fungible IDs. Resolve one via /v1/fungibles/{chain_id}:{address}.
Values precomputed: DeBank token objects return amount and price but not a USD value; you multiply them. Zerion returns value per position.
One endpoint for tokens and DeFi: Zerion serves both wallet tokens and DeFi positions from /positions/. Switch via filter[positions]=only_simple (wallet only), only_complex (DeFi only), or no_filter (both).
Flattened DeFi: DeBank nests positions under protocol objects with supply/borrow/reward token lists. Zerion returns one row per position tagged with protocol_module and position_type (including loan for debt). Reconstruct protocol grouping client-side via relationships.dapp.data.id.
No token dictionary: DeBank history references tokens by id into a separate token_dict. Zerion inlines fungible_info in each transfer.
Transaction categorization: DeBank’s cate_id is coarse (send, receive, approve, or null), so most contract interactions arrive uncategorized and you infer intent from tx.name and project_id. Zerion always sets a decoded operation_type (trade, deposit, withdraw, mint, and so on).
Response shape: Zerion uses JSON:API. Payloads live under data[].attributes with related entities under data[].relationships.
Spam filtering: DeBank curates via is_core, is_verified, is_suspicious, is_scam, and credit_score signals (plus the is_all flag). Zerion uses filter[trash]=only_non_trash. See spam filtering for the full taxonomy.
Pagination: DeBank pages history with start_time; Zerion returns a fully-formed links.next URL you can fetch as-is. See pagination.
Have a use case we don’t cover or need assistance with the migration? Our team is happy to help! Reach out via the chat widget on dashboard.zerion.io, or email us.