An NFT API gives your app ready-made answers to questions the blockchain cannot answer quickly on its own: which NFTs does this wallet hold, what does this token look like, who traded it and for how much. Most teams should rent this from a provider; a few should build their own indexer, and this guide explains how to tell which you are.
Why NFT data needs an API at all
A blockchain node can tell you who owns token #42 of a given contract. It cannot efficiently tell you every NFT a wallet holds across thousands of contracts, because that requires scanning every transfer event ever emitted. Then there is metadata: an ERC-721 token returns a tokenURI, which points to a JSON file (often on IPFS or a web server), which points to an image that may be slow, missing, or malicious. NFT APIs exist to do this scanning, fetching, caching and cleaning once, for everyone.
Under the hood, a provider listens to standard events defined in ERC-721 (Transfer) and ERC-1155 (TransferSingle, TransferBatch), builds an ownership table, resolves metadata, and exposes it through REST, GraphQL or webhooks.
The main categories of NFT API
| Category | Typical endpoints | Used for |
|---|---|---|
| Ownership and metadata | NFTs by owner, NFTs by collection, token metadata, refresh metadata | Wallet galleries, profile pages, token-gating |
| Activity and sales | Transfers, sales history, floor price, collection stats | Marketplaces, portfolio trackers, analytics |
| Webhooks and streams | Notify on transfer to or from an address, on mint, on sale | Real-time UIs, game servers, fraud monitoring |
| Minting and transactions | Mint to address or email, gas sponsorship, batch airdrops | Loyalty programs, ticketing, onboarding non-crypto users |
| Marketplace and orders | Read and create listings and offers, fulfill orders | Aggregators, trading bots, embedded buy buttons |
| Storage | Upload and pin files and metadata to IPFS or Arweave | Creator tools, minting platforms |
| Wallet | Create embedded wallets, sign, recover | Consumer apps that hide seed phrases |
Few providers cover every row well. Node infrastructure companies such as Alchemy, QuickNode and Moralis offer broad ownership and metadata APIs across EVM chains. Large marketplaces such as OpenSea expose APIs for their own listings and collection data. On Solana, the Digital Asset Standard (DAS) API, implemented by RPC providers such as Helius, is the common way to query regular and compressed NFTs. Minting and embedded-wallet APIs are a separate category of vendor.
How to evaluate a provider
- List the exact queries your app makes. "All NFTs owned by this wallet, with images, filtered to these five collections, sorted by acquisition date" is a specification you can test. "NFT data" is not.
- Check chain coverage, including testnets. Confirm every chain you need now and in the next year, and whether coverage includes ERC-1155 and, on Solana, compressed NFTs.
- Measure freshness. Transfer an NFT on a testnet and time how long until the API reflects it. Marketplaces and games need seconds; galleries can tolerate minutes.
- Test metadata quality. Pick tokens with IPFS metadata, on-chain SVG metadata, and broken URIs. See whether the provider caches images, handles slow gateways and lets you force a refresh.
- Check spam filtering. Wallets receive large numbers of unsolicited airdropped NFTs, many of them phishing lures. A good provider flags or hides them.
- Model the bill. Pricing is usually per request or per "compute unit". Multiply by your expected daily active users and the calls per page load, and compare tiers.
- Read the deprecation history. Several NFT data products have been shut down, merged or repriced since the 2022 market downturn. Ask how much notice customers get, and keep your integration behind an internal interface so you can switch.
Build vs buy
Renting an API is the right default. Building your own indexer starts to make sense when:
- You need data no provider offers, such as custom game state derived from your own contracts.
- Your request volume makes per-call pricing more expensive than running infrastructure.
- You need guaranteed freshness and uptime that you control, as an exchange or large marketplace does.
- You support a chain that providers do not cover well.
A middle path is common: use a provider for wallet-wide ownership and metadata, and index your own contracts yourself with a subgraph (The Graph) or an open-source indexing framework. Your own contracts are a small, well-understood dataset, and owning that index removes a dependency for your core features.
What building an NFT API involves
Whether you are building an internal indexer or launching an NFT API as a product, the components are similar.
Ingestion
Follow the chain head through your own nodes or an RPC provider, fetch logs for transfer events, and decode them. Handle reorganizations: blocks near the head can be replaced, so either wait for finality or write ingestion that can roll back. Backfilling history for a large chain is a substantial batch job in itself.
Ownership model
For ERC-721, the latest transfer wins. For ERC-1155, maintain balances per owner per token ID, adding and subtracting across single and batch transfers. Non-standard contracts (early collections like CryptoPunks predate ERC-721) need custom adapters.
Metadata pipeline
Call tokenURI or uri, resolve ipfs:// and ar:// links through gateways you control, parse JSON, fetch and resize media, and store everything with timestamps. Expect timeouts, oversized files, invalid JSON and changing metadata. Run fetches through a queue with retries and limits, and sanitize SVGs and HTML before serving them, since token media can contain scripts. The IPFS development guide explains gateways and pinning.
Market data
Sales are not a standard event. You must decode each marketplace's contracts (for example Seaport order fulfillments, Blur's exchange, and others) to attribute prices, then filter wash trades before computing floor prices and volumes.
Serving layer
Expose REST or GraphQL with pagination, API keys, per-key rate limits, usage metering, caching, and webhooks with retries and signing. Add an admin dashboard for key management, usage and billing, plus status monitoring.
Security
Treat all token metadata as untrusted input. Protect API keys (never in client bundles; use a backend proxy or domain-restricted keys), and authenticate webhooks with signatures so receivers can verify them.
Cost drivers
| Driver | Renting an API | Running your own |
|---|---|---|
| Number of chains | Higher tier or more providers | Nodes, backfill and adapters per chain |
| Request volume | Scales linearly with usage | Mostly fixed infrastructure plus caching |
| Freshness requirement | Usually included; webhooks may cost extra | Head-following ingestion and reorg handling |
| Media handling | Included, quality varies | Storage, CDN, image processing, moderation |
| Engineering time | Integration: days to weeks | Initial build: months; ongoing on-call |
As a reasoned estimate, an indexer covering your own contracts on one EVM chain is a few weeks of one backend engineer's time. A general-purpose multi-chain NFT API with metadata, sales and webhooks is a multi-quarter effort for a small infrastructure team, with permanent operating costs for nodes, storage and support.
Integration patterns that hold up
However you source the data, a few patterns make an NFT integration more robust:
- Wrap the provider: put every external call behind your own service with a stable internal schema. Swapping vendors then means rewriting one adapter, not your app.
- Cache aggressively, invalidate on events: metadata rarely changes, so cache it for hours or days, and use webhooks to invalidate ownership caches when a transfer touches your users.
- Verify where it counts: use the API for display and discovery, but confirm ownership with a direct contract call before granting something valuable, such as event entry or a payout.
- Handle partial data: render a placeholder when metadata is missing rather than failing the whole page. Collections with broken metadata are common.
- Watch your quota: alert on request volume, because one inefficient loop in a frontend can burn a monthly allowance in hours.
Where NFT APIs fit in a product
Marketplaces need ownership, activity and order APIs; the NFT marketplace development guide shows how these fit together. Aggregators depend on order APIs from many venues, covered in the NFT aggregator guide. Wallets need ownership, metadata and spam filtering, which the Web3 wallet development guide discusses. Multichain products need a consistent schema across networks; see multichain NFT support.
Frequently asked questions
Can I just query the blockchain directly instead of using an NFT API?
For a single known contract and token, yes: call ownerOf and tokenURI on a node. For "everything this wallet owns" or "all sales in a collection", you need an index, either rented or your own.
Are NFT APIs reliable for token-gating?
For most content, yes. For high-value gates, verify ownership directly on-chain at the moment of access as well, since indexes can lag the chain by seconds or minutes.
Why do some NFTs show no image through an API?
The metadata may point to a server that is offline, an IPFS file nobody pins, or media in a format the provider does not render. The API can only show what it can retrieve.
Do I need different APIs for Solana and EVM chains?
Often yes. Solana NFTs use Metaplex standards and are usually queried through the DAS API, while EVM chains use ERC-721 and ERC-1155 events. Some providers cover both behind one interface.
How do providers detect spam NFTs?
Usually with heuristics and reports: airdrops to many wallets, links in names, collections with no organic trading, and known phishing contracts. No method is perfect, so let users hide items manually too.
Should I expose my API key in a web app?
No. Route calls through your own backend, or use keys restricted by domain and with low limits. Exposed keys get scraped and used up by others.