Endpoints and response schema

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, DeFi positions, transactions, PnL and NFTs for any address.Fungibles Search and list tokens, with metadata, prices and charts.Chains Every supported chain, with IDs and metadata.NFTs Single or batch NFT lookups by reference or ID.Swap & bridge Swap and bridge quotes routed across DEXs and bridges.Gas prices Current gas price estimates on every chain.DApps Protocol names, icons and categories.Subscriptions (Webhooks) Webhooks on wallet activity. Pick the wallets and chains to watch.

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.

Response structure

Every response follows a consistent JSON:API format:

{
  "links": {
    "self": "https://api.zerion.io/v1/...",
    "next": "https://api.zerion.io/v1/...?page[after]=..."
  },
  "data": {
    "type": "positions",
    "id": "unique-id",
    "attributes": { ... },
    "relationships": { ... }
  }
}

Field	Description
`links`	Pagination - `self` for the current page, `next` for the next page
`data`	A single resource object or an array of them
`type`	Resource type (e.g., `positions`, `transactions`, `fungibles`)
`id`	Unique identifier for the resource
`attributes`	The resource’s data fields
`relationships`	Links to related resources

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. The format of any of them may change without that being a breaking change.

"id": "820ee2f1ca8ccb716f6beb5e450908a028be890ec44aba87c739b416ef41e197"

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.

Get started

Core concepts

Migrating to Zerion API

Endpoints and response schema

Endpoint categories

Response structure

Resource IDs

Next steps

​Endpoint categories

​Response structure

​Resource IDs

​Next steps

Endpoint categories

Response structure

Resource IDs

Next steps