NFT API Service Providers: Choosing One or Building Your Own

An NFT API answers questions that a blockchain node cannot answer quickly, such as which NFTs a wallet holds, what a token's image is and what its sales history looks like. This guide explains how NFT APIs work, how to test a provider, and when a team should build its own indexer instead.

Why NFT data needs an API

A blockchain node can report the owner of token #42 in one contract. It cannot quickly list every NFT a wallet holds across thousands of contracts, because that list requires a scan of every transfer event ever recorded.

Metadata adds a second problem. An ERC-721 token returns a tokenURI that points to a JSON file, often on IPFS or a web server, and the JSON file then points to an image, which may load slowly, be missing or contain harmful code. An NFT API does the scanning, fetching, caching and cleaning once and serves the results to every customer.

The company that runs the NFT API, the provider, listens for standard events on each chain. ERC-721 tokens emit Transfer, and ERC-1155 tokens emit TransferSingle and TransferBatch. The provider builds an ownership table from these events, resolves the metadata and serves the data through REST, GraphQL or webhooks.

Types of NFT data API

Examples of NFT API providers

No single provider covers every row of the table, and the examples below come from each provider's public documentation in October 2026.

The Digital Asset Standard (DAS) is an open specification that several Solana RPC providers besides Helius implement. Minting APIs and embedded-wallet APIs usually come from other vendors, not from the data providers in this table.

How to evaluate an NFT API provider

1. List the exact queries your app makes. "All NFTs owned by this wallet, with images, from these five collections, sorted by date acquired" is a query you can test. "NFT data" is not.
2. Check chain coverage, including testnets. Confirm every chain you need now and next year, and confirm that coverage includes ERC-1155 tokens and, on Solana, compressed NFTs.
3. Measure freshness. Transfer an NFT on a testnet and time how long the API takes to show the change. Marketplaces and games need seconds, while galleries can wait minutes.
4. Test metadata quality. Pick tokens with IPFS metadata, on-chain SVG metadata and broken URIs. Check whether the provider caches images, handles slow gateways and lets you force a refresh.
5. Check spam filtering. Wallets receive many unwanted airdropped NFTs, and many of them link to phishing sites, so the provider should flag or hide them.
6. Model the bill. Most providers charge per request or per compute unit, and each method has its own unit cost. Multiply the cost per page load by your expected daily active users.
7. Read the provider's history. Several NFT data products have shut down, merged or changed prices since the 2022 market downturn, so ask how much notice customers get and keep your integration behind an internal interface, so you can switch providers.

Build or buy

Renting an NFT API is the default for most teams, and building your own indexer makes sense in four cases:

• You need data no provider offers, such as game state from your own contracts.
• At your request volume, per-call pricing costs more than running your own servers.
• You need freshness and uptime under your own control, as an exchange or large marketplace does.
• You support a chain that providers cover poorly.

Many teams rent an API and also build a small indexer. They use a provider for wallet-wide ownership and metadata, and index their own contracts with a subgraph on The Graph or an open-source indexing framework. Their own contracts produce a small amount of data whose structure they know, and indexing it themselves keeps the product's core features working when a data provider fails or shuts down.

What building an NFT API involves

An internal indexer and a public NFT API product have the same main parts.

Ingestion

The indexer follows new blocks through your own nodes or an RPC provider, and fetches and decodes the logs for transfer events. The most recent blocks can still be replaced by other blocks, which is called a reorganization, so the indexer must either wait until a block is final and can no longer change, or be able to undo the data from a replaced block. Loading the full history of a large chain is a large batch job of its own.

Ownership model

For ERC-721, the latest transfer sets the owner. For ERC-1155, the indexer keeps a balance per owner per token ID and updates it on single and batch transfers, while older contracts that predate the standards, such as CryptoPunks, need custom adapters.

Metadata pipeline

The pipeline calls tokenURI (ERC-721) or uri (ERC-1155) on each token. It resolves ipfs:// and ar:// links through gateways you control, parses the JSON, fetches and resizes the media and stores everything with timestamps. Expect timeouts, oversized files, invalid JSON and metadata that changes.

Run fetches through a queue with retries and limits, and clean SVG and HTML files before you serve them, because token media can contain scripts. The IPFS development guide explains gateways and pinning.

Market data

Sales are not a standard event, so the indexer must decode each marketplace's contracts, such as OpenSea's Seaport protocol and Blur's exchange, to find sale prices. It then filters out wash trades, where one person trades with themselves to fake activity, before it calculates floor prices and volumes.

Serving layer

The serving layer exposes REST or GraphQL with pagination, API keys, rate limits per key, usage metering and caching. Webhooks need retries and signatures, and an admin dashboard handles keys, usage, billing and status monitoring.

Security

Treat all token metadata as untrusted input. Keep API keys out of browser code by routing calls through a backend or using keys restricted to your domain. Sign webhook payloads, so receivers can check that each call came from you.

Cost drivers

The figures in this section are estimates, not quotes. An indexer for your own contracts on one EVM chain takes one backend engineer a few weeks. A general multichain NFT API with metadata, sales and webhooks takes a small infrastructure team several quarters and has permanent costs for nodes, storage and support.

Integration patterns

• Wrap the provider. Put every external call behind your own service with a stable internal schema, so a change of vendor means a new adapter, not a rewrite of the app.
• Cache data, and clear the ownership cache after transfers. Metadata rarely changes, so cache it for hours or days. Use webhooks to clear the ownership cache when a transfer involves one of your users.
• Verify ownership on-chain for valuable actions. Use the API for display and search, but before you grant event entry or a payout, confirm ownership with a direct contract call.
• Handle missing data. Show a placeholder when metadata is missing, so the rest of the page still loads, because many collections have broken metadata.
• Watch your quota. Set an alert on request volume, because one inefficient loop in a frontend can use up a monthly allowance in hours.

Where NFT APIs fit in a product

Marketplaces need ownership, activity and order APIs, and the NFT marketplace development guide shows how the parts connect. Aggregators read order APIs from many marketplaces, as the NFT aggregator guide explains. Wallets need ownership data, metadata and spam filtering, which the Web3 wallet development guide covers. The multichain NFT support page explains how to keep NFT data in one format across several networks.

Frequently asked questions