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.
Endpoint parity
| Use case | DeBank Cloud API | Zerion API |
|---|
| Tokens + DeFi (one call) | Two requests (all_token_list + all_complex_protocol_list) | GET /v1/wallets/{address}/positions/?filter[positions]=no_filter |
| Net worth + 24h change | GET /v1/user/total_balance | GET /v1/wallets/{address}/portfolio |
| Net worth over time | GET /v1/user/total_net_curve | GET /v1/wallets/{address}/charts/{period} |
| Token balances | GET /v1/user/all_token_list (or token_list per chain) | GET /v1/wallets/{address}/positions/?filter[positions]=only_simple |
| DeFi positions | GET /v1/user/all_complex_protocol_list | GET /v1/wallets/{address}/positions/?filter[positions]=only_complex |
| Wallet history | GET /v1/user/all_history_list (or history_list per chain) | GET /v1/wallets/{address}/transactions/ |
| NFTs | GET /v1/user/all_nft_list | GET /v1/wallets/{address}/nft-positions/ |
| Chains used by a wallet | GET /v1/user/used_chain_list | Derive from positions_distribution_by_chain on /portfolio |
| Realtime updates | (polling) | Transaction webhooks |
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.
Token balances
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.
Field mapping
| DeBank (token object) | Zerion (data[].attributes.…) |
|---|
symbol, display_symbol, optimized_symbol | fungible_info.symbol |
name | fungible_info.name |
decimals | fungible_info.implementations[].decimals |
id (contract address, or chain short name for native) | fungible_info.implementations[].address (null for native) |
chain (short name, e.g. eth) | relationships.chain.data.id (full ID, e.g. ethereum) |
amount (decimal) | quantity.float (decimal number). Also quantity.int (raw integer string) and quantity.numeric (decimal string). |
raw_amount (raw integer) | quantity.int |
price | price |
amount × price (compute client-side) | value (USD, precomputed) |
logo_url | fungible_info.icon.url |
is_verified | fungible_info.flags.verified |
is_core, is_suspicious, credit_score, is_all=false (curation signals) | filter[trash]=only_non_trash (request param) |
time_at (first seen, unix) | 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.
Net worth
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.
Field mapping
DeBank (total_balance) | Zerion (/portfolio → data.attributes.…) |
|---|
total_usd_value | total.positions |
chain_list[].usd_value | positions_distribution_by_chain (keyed by chain ID) |
| (compute from token + protocol values) | positions_distribution_by_type (wallet, deposited, borrowed, locked, staked) |
| (no equivalent) | changes.absolute_1d, changes.percent_1d (24h change) |
total_net_curve (separate endpoint) | /wallets/{address}/charts/{period} |
DeFi positions
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).
Field mapping
DeBank (protocol / portfolio_item_list[]) | Zerion (data[].attributes.…) |
|---|
protocol name, id | protocol, relationships.dapp.data.id |
protocol logo_url | application_metadata.icon.url |
portfolio_item_list[].name (human label, e.g. Lending, Liquidity Pool) | protocol_module (lending, staked, liquidity_pool, locked, rewards, vesting, deposit, investment, yield) |
portfolio_item_list[].detail_types (machine list, e.g. ["lending"], ["common"]) | position_type (deposit, loan, locked, staked, reward, investment) |
detail.supply_token_list[] | rows with position_type: deposit / staked |
detail.borrow_token_list[] (present when the position has debt) | rows with position_type: loan |
detail.reward_token_list[] | rows with position_type: reward |
detail.health_rate (lending health factor) | No direct equivalent. Derive from supplied vs borrowed value. |
token amount | quantity.float |
token price, amount × price | price, value |
stats.asset_usd_value, stats.debt_usd_value, stats.net_usd_value | 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.
Wallet history
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.
Field mapping
DeBank (history_list[].…) | Zerion (data[].attributes.…) |
|---|
id (tx hash) | hash |
time_at (unix) | mined_at (ISO 8601) / mined_at_block |
chain (short name) | relationships.chain.data.id (full ID) |
cate_id (coarse: send, receive, approve, or null) + tx.name (method name) | operation_type (always set: send, receive, trade, approve, deposit, withdraw, mint, burn, claim, execute, deploy) |
sends[] / receives[] | transfers[] with direction (out / in) |
sends[].amount / receives[].amount | transfers[].quantity.float (also .int, .numeric) |
sends[].to_addr / receives[].from_addr | transfers[].recipient / transfers[].sender |
token_id → look up in token_dict (an address, eth for native, or a non-address id for NFTs) | transfers[].fungible_info (inlined, no dictionary lookup) |
token_approve.spender, .value | operation_type: approve with acts[] / approvals detail |
tx.from_addr / tx.to_addr | sent_from / sent_to |
tx.usd_gas_fee / tx.eth_gas_fee (present on wallet-initiated txs, not on incoming transfers) | fee.value / fee.quantity.float |
is_scam (per-transaction flag) | flags.is_trash |
project_id → project_dict | relationships.dapp.data.id (dApp slug, e.g. uniswap-v3) |
cex_id → cex_dict | No direct equivalent (Zerion does not label CEX deposit addresses) |
Filter mapping
| DeBank param | Zerion equivalent |
|---|
chain_id=eth (single chain) | filter[chain_ids]=ethereum (comma-separated for multiple) |
token_id=0xa0b8… (contract address) | filter[fungible_ids]=<zerion-fungible-id>. Zerion uses its own fungible IDs, not contract addresses. Look one up via /v1/fungibles?filter[search_query]=… or /v1/fungibles/{chain_id}:{address}. |
start_time (unix) | filter[min_mined_at] (and filter[max_mined_at], ms epoch) |
page_count (max 20) | page[size] |
| (paging cursor) | Follow links.next from the response |
NFTs
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 (nft_list[].…) | Zerion (data[].attributes.…) |
|---|
contract_id | nft_info.contract_address |
inner_id | nft_info.token_id |
name | nft_info.name |
collection_name (flat string) | collection_info.name |
content / thumbnail_url | nft_info.content |
attributes[] (trait_type / value) | No direct equivalent (Zerion does not return a flat trait list) |
usd_price (floor-based) | value (floor value); price is the floor price |
amount (quantity held, for ERC-1155) | amount |
chain | relationships.chain.data.id |
Replace DeBank’s start_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/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:
- Authentication: DeBank uses an
AccessKey header. 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
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.
Get in touch
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.