> ## Documentation Index
> Fetch the complete documentation index at: https://developers.zerion.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Endpoints and response schema

> Overview of Zerion API endpoint categories for wallets, chains, fungibles, NFTs, and swaps, plus the JSON:API response envelope and resource object structure.

Zerion API provides real-time, normalized access to onchain data through RESTful endpoints. All requests go to `https://api.zerion.io` and require [authentication](/authentication) via HTTP Basic Auth. Responses follow the [JSON:API](https://jsonapi.org/) specification.

## Endpoint categories

### [Wallets](/api-reference/wallets/get-wallet-portfolio)

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](/api-reference/fungibles/get-list-of-fungible-assets)

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](/api-reference/chains/get-list-of-all-chains)

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

### [NFTs](/api-reference/nfts/get-list-of-nfts)

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

### [Swap & Bridge](/api-reference/swap/get-swap-and-bridge-quotes)

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](/api-reference/gas/get-list-of-all-available-gas-prices)

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

### [DApps](/api-reference/dapps/get-list-of-dapps)

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

### [Subscriptions (Webhooks)](/api-reference/subscriptions-to-transactions/create-subscription)

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](https://jsonapi.org/) format:

```json theme={null}
{
  "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 - and the format of any of them may change without that being a breaking change.

```json theme={null}
"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](/api-reference/fungibles/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](/api-reference/chains/get-list-of-all-chains).

## Next steps

<CardGroup cols={3}>
  <Card title="Pagination & filtering" icon="filter" href="/pagination-and-filtering">
    Paginate results and apply filters.
  </Card>

  <Card title="Error handling" icon="circle-exclamation" href="/error-handling">
    Error codes and how to handle them.
  </Card>

  <Card title="Rate limits" icon="gauge" href="/rate-limits">
    Request limits and how to stay within them.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.