- One call for tokens + DeFi: Collapse DeBank’s
all_token_listandall_complex_protocol_listinto a single/positions/?filter[positions]=no_filterresponse. - 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 multiplyamountbypriceyourself.
Endpoint parity
Token balances
DeBank returns a flat array of token objects, where each token carriesamount 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.
Field mapping
price and value are null for tokens without a reliable price. Guard for null before summing or formatting.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.Net worth
DeBank’stotal_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.
Field mapping
DeFi positions
DeBank’sall_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).
Field mapping
Wallet history
DeBank’shistory_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.
Field mapping
Filter mapping
NFTs
DeBank’sall_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.
cURL
Pagination
Replace DeBank’sstart_time cursor with Zerion’s links.next URL. Each Zerion response includes a fully-formed next-page link you can fetch as-is.
Realtime updates
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.Differences from DeBank
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/tokenendpoints. 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’supdated_atreflects the last balance change, not first acquisition.
- Authentication: DeBank uses an
AccessKeyheader. Zerion uses HTTP Basic Auth. Get a key at dashboard.zerion.io. - 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
amountandpricebut not a USD value; you multiply them. Zerion returnsvalueper position. - One endpoint for tokens and DeFi: Zerion serves both wallet tokens and DeFi positions from
/positions/. Switch viafilter[positions]=only_simple(wallet only),only_complex(DeFi only), orno_filter(both). - Flattened DeFi: DeBank nests positions under protocol objects with
supply/borrow/rewardtoken lists. Zerion returns one row per position tagged withprotocol_moduleandposition_type(includingloanfor debt). Reconstruct protocol grouping client-side viarelationships.dapp.data.id. - No token dictionary: DeBank history references tokens by id into a separate
token_dict. Zerion inlinesfungible_infoin each transfer. - Transaction categorization: DeBank’s
cate_idis coarse (send,receive,approve, ornull), so most contract interactions arrive uncategorized and you infer intent fromtx.nameandproject_id. Zerion always sets a decodedoperation_type(trade,deposit,withdraw,mint, and so on). - Response shape: Zerion uses JSON:API. Payloads live under
data[].attributeswith related entities underdata[].relationships. - Spam filtering: DeBank curates via
is_core,is_verified,is_suspicious,is_scam, andcredit_scoresignals (plus theis_allflag). Zerion usesfilter[trash]=only_non_trash. See spam filtering for the full taxonomy. - Pagination: DeBank pages history with
start_time; Zerion returns a fully-formedlinks.nextURL you can fetch as-is. See pagination.