Summary
Standard Solana JSON-RPC nodes expose core methods like getAccountInfo and getProgramAccounts, but they do not return decoded NFT metadata, collection groupings, or compressed NFT (cNFT) state. Providers that include enhanced APIs add indexed, NFT-aware endpoints on top of the raw node so you can query assets, collections, and token metadata without writing your own DAS indexer. OnFinality offers Solana RPC and dedicated node infrastructure with HTTP and WebSocket transports, and you can pair it with an indexing layer for NFT-specific reads.
Quick recommendation
If your application needs decoded NFT metadata, collection membership, or compressed NFT (cNFT) state, a plain Solana JSON-RPC node will not give it to you. You need a provider that layers an indexed, NFT-aware API on top of the node. In practice that means one of two setups:
- A provider with a built-in enhanced NFT API (often a Digital Asset Standard, or DAS, endpoint) that returns assets, collections, and metadata in a single call.
- A raw Solana RPC provider plus your own indexer, where you run the node and a separate indexing service that reads on-chain state and serves NFT queries.
OnFinality provides Solana RPC and dedicated node infrastructure over HTTP and WebSocket, which is the node layer both setups depend on. If you want NFT-aware reads without operating an indexer, confirm the provider's enhanced API surface before you commit. If you want full control over how NFT data is shaped, run the node through a provider like OnFinality and add your own indexing layer.
Why standard Solana RPC stops short of NFT data
Solana's base JSON-RPC is account-oriented, not asset-oriented. A node can tell you the raw bytes stored in an account, but it does not know that a particular account is an NFT, which collection it belongs to, or what its off-chain metadata says. That decoding work is the job of an indexer.
This matters because most NFT reads are not single-account lookups. They are queries like "all NFTs owned by this wallet," "every item in this collection," or "the current state of this compressed NFT tree." Answering those from raw RPC means scanning many accounts and parsing metadata yourself, which is slow and expensive at scale.
Enhanced NFT APIs exist to close that gap. They maintain an index of assets and expose methods that return structured results, so your client does not have to reconstruct NFT state from raw accounts.
What "enhanced API for NFT data" actually means
The phrase covers a few different things, and providers use it loosely. When you evaluate a provider, separate these layers:
| Layer | What it returns | Typical method shape |
|---|---|---|
| Raw node RPC | Account bytes, balances, slots | getAccountInfo, getProgramAccounts |
| Token/metadata RPC | SPL token and Metaplex metadata accounts | getTokenAccountsByOwner, metadata account reads |
| Enhanced asset API (DAS-style) | Decoded assets, collections, ownership, cNFTs | getAssetsByOwner, getAsset, getAssetsByGroup |
| Custom indexer | Whatever schema you define | Your own HTTP/GraphQL endpoint |
The DAS-style layer is what most developers mean by "enhanced NFT API." It is an indexed service, not a node method, so it can live at the same provider or at a separate one.
Provider evaluation matrix for NFT workloads
Use this to compare providers on the dimensions that actually affect NFT reads. Put your own weights on each row based on how much NFT data your app serves.
| Evaluation area | What to confirm | Why it matters for NFT data |
|---|---|---|
| Enhanced/DAS API | Whether an indexed asset API is offered, and which methods | Determines if you can query assets without your own indexer |
| cNFT support | Whether compressed NFTs are indexed | Standard RPC cannot enumerate cNFTs efficiently |
| Raw node access | HTTP and WebSocket availability | Needed for writes, subscriptions, and fallback reads |
| Transport | HTTP, WebSocket, and any gRPC-style options | Subscriptions and real-time mints need WebSocket |
| Dedicated capacity | Whether you can get a dedicated node | Isolates heavy getProgramAccounts scans from shared traffic |
| Data freshness | How often the index updates | Stale indexes return wrong ownership after transfers |
| Failover | How you switch endpoints if one degrades | NFT marketplaces cannot afford silent read failures |
OnFinality sits in the raw node and dedicated capacity rows: it provides Solana RPC over HTTP and WebSocket, and dedicated nodes for workloads that need isolated capacity. For the enhanced asset layer, confirm the indexing service you plan to use and how it connects to your node.
Connecting to Solana RPC
Whatever enhanced layer you choose, it ultimately reads from a Solana node. OnFinality exposes a public HTTP endpoint and a matching WebSocket endpoint for Solana mainnet:
# HTTP JSON-RPC
curl https://solana.api.onfinality.io/public \
-X POST -H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"getHealth"}'
// WebSocket subscription for account changes (e.g. a mint or metadata account)
import WebSocket from "ws";
const ws = new WebSocket("wss://solana.api.onfinality.io/public-ws");
ws.on("open", () => {
ws.send(JSON.stringify({
jsonrpc: "2.0",
id: 1,
method: "accountSubscribe",
params: [
"<METADATA_ACCOUNT_PUBKEY>",
{ encoding: "jsonParsed", commitment: "confirmed" }
]
}));
});
ws.on("message", (data) => {
console.log("account update:", data.toString());
});
For production, point your app at a dedicated or managed endpoint rather than the public one. See Solana RPC for the current endpoint details and RPC pricing for capacity options.
Reading NFT data without an enhanced API
If you decide to run your own indexer, the node still does the heavy lifting. A common pattern is to fetch token accounts for a wallet, then resolve the metadata account for each mint:
// 1. Get token accounts owned by a wallet
const owner = "<WALLET_PUBKEY>";
const res = await fetch("https://solana.api.onfinality.io/public", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
jsonrpc: "2.0",
id: 1,
method: "getTokenAccountsByOwner",
params: [owner, { programId: "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA" }, { encoding: "jsonParsed" }]
})
});
const { result } = await res.json();
console.log(result.value.length, "token accounts");
From there you derive the Metaplex metadata PDA for each mint and read it, or hand the mint list to your indexer. This is more work than calling getAssetsByOwner, but it keeps you independent of any single provider's enhanced API.
When to use an enhanced API vs your own indexer
There is no universally correct answer. The tradeoff is control versus operational load.
- Choose a provider's enhanced NFT API when you want fast time-to-market, your queries fit the provider's method set, and you are comfortable depending on their index freshness and schema.
- Run your own indexer on a managed node when you need custom NFT fields, cross-program joins, or a schema your product owns, and you can absorb the indexing and backfill work.
- Use both when you want the enhanced API for common reads and your own index for product-specific queries, with the node as the shared source of truth.
A hybrid setup is common in marketplaces: enhanced API for discovery and search, own index for ranking, pricing, and analytics.
Production readiness checklist
Before you route NFT traffic to any provider, confirm these items:
- Endpoint isolation. Heavy
getProgramAccountsor metadata scans should not share capacity with latency-sensitive reads. Consider a dedicated node. - Transport coverage. You have both HTTP and WebSocket endpoints, and your client handles reconnects.
- Index freshness expectations. You know how quickly ownership changes appear in the enhanced API after a transfer or mint.
- Failover path. You can switch to a second endpoint or provider without redeploying.
- Commitment levels. You understand how
processed,confirmed, andfinalizedaffect what NFT state you see. - Rate and burst behavior. You know how your provider handles traffic spikes during mints or drops.
- Observability. You log request latency, error rates, and index lag so you can detect degradation early.
Common failure modes with NFT data on Solana
- Stale ownership. The enhanced index has not caught up with a recent transfer, so the app shows the wrong owner. Mitigate by reading final state for ownership-critical actions.
- cNFT enumeration gaps. Compressed NFTs are not always indexed by every provider. Confirm cNFT support explicitly if your app uses them.
- Metadata fetch failures. Off-chain metadata URIs can be slow or unavailable; cache aggressively and handle timeouts.
getProgramAccountsoverload. Broad scans against shared endpoints can be slow or throttled. Scope filters tightly or move to a dedicated node.- Schema drift. Enhanced API response shapes can change between versions. Pin your client to a known version and test upgrades.
Key Takeaways
- Standard Solana RPC does not return decoded NFT data; enhanced APIs are indexed services layered on top of a node.
- "Enhanced API" usually means a DAS-style asset API with methods like
getAssetsByOwnerandgetAssetsByGroup. - You can get NFT data either from a provider's enhanced API or by running your own indexer against a raw node.
- OnFinality provides Solana RPC over HTTP and WebSocket plus dedicated nodes, which is the node layer both approaches need.
- Evaluate providers on enhanced API coverage, cNFT support, transport, dedicated capacity, index freshness, and failover.
- Confirm index freshness and cNFT support before committing, and keep a failover endpoint ready.
Frequently Asked Questions
Does OnFinality include an enhanced NFT API? OnFinality provides Solana RPC and dedicated node infrastructure over HTTP and WebSocket. For NFT-specific enhanced reads, confirm the indexing layer you plan to use and how it connects to your node. See Solana RPC for endpoint details.
Can I get NFT metadata from a standard Solana RPC node? You can read raw token and metadata accounts, but you must decode and index them yourself. A standard node does not return structured asset or collection data.
What is a DAS API?
Digital Asset Standard (DAS) is a common interface for querying indexed Solana assets, including NFTs and compressed NFTs, with methods like getAsset and getAssetsByOwner.
Do I need a dedicated node for NFT workloads?
Not always, but heavy metadata scans or getProgramAccounts queries benefit from isolated capacity so they do not affect other traffic. See dedicated nodes.
How do I switch providers without breaking my app? Keep endpoint configuration external, support multiple endpoints, and test failover. A short provider selection checklist helps you compare options before migrating.
Where can I see which networks OnFinality supports? Browse supported RPC networks and check RPC pricing for capacity and plan details.