Skip to main content
The Zerion API provides real-time, normalized access to onchain data through RESTful endpoints. All requests go to https://api.zerion.io and require authentication via HTTP Basic Auth. Responses follow the JSON:API specification.

​
Endpoint categories

​
Wallets

Portfolio, positions, transactions, PnL, and NFTs - all scoped to a wallet address. This is the core of the API. Positions include both fungible tokens and DeFi protocol positions. NFT data is split into individual holdings, collections, and a portfolio summary. All positions and transactions come with icons, labels, links, metadata, and relationships. Everything is ready to use immediately in interfaces without additional interpretation or enrichment.

​
Fungibles

Token metadata, pricing, and market data. Search and filter across all supported tokens, look up by Zerion ID or by chain and contract address, and fetch historical price charts.

​
Chains

The full list of supported blockchains with metadata. Useful for populating chain selectors or validating chain IDs before making other calls.

​
NFTs

Look up individual NFTs by reference or unique ID, with support for batch fetching.

​
Swap & Bridge

Quotes for token swaps and cross-chain bridges, routed across DEXs and bridge protocols. First check which tokens are available for a route, then request offers.

​
Gas Prices

Current gas price estimates across all supported chains. Useful for displaying fee estimates or optimizing transaction timing.

​
DApps

Metadata for decentralized applications - names, icons, and categories. DApp info is also embedded in position and transaction responses to provide context.

​
Subscriptions (Webhooks)

Push-based notifications for wallet activity - no polling required. Create subscriptions, manage which wallets and chains to monitor, and update webhook URLs.

​
Response structure

Every response follows a consistent JSON:API format:

​
Resource IDs

Every resource carries an id. Treat these as opaque strings: match them, store them, pass them back, but don’t parse them or derive meaning from their shape. Some are hashes, some are chain slugs, some are composite - and the format of any of them may change without that being a breaking change.
Two consequences worth designing around:
  • Don’t reconstruct an ID client-side. To find a token by chain and contract address, call get fungible asset by implementation rather than assembling an ID yourself.
  • Don’t use an ID as a stable primary key across resources. Position IDs in particular are derived from wallet, chain, and protocol context, so the same token held in two places has two different position IDs.
The one ID you can rely on the shape of is a chain ID, because it is the value you pass into filter[chain_ids] and read from the chains endpoint.

​
Next steps

Pagination & filtering

Paginate results and apply filters.

Error handling

Error codes and how to handle them.

Rate limits

Request limits and how to stay within them.