OnFinality

Posted on Sep 14 Originally published at onfinality.io

Reliable Solana RPC for NFT Data APIs: What to Check

#web3 #blockchain #solana #tutorial

Quick recommendation

If you are building an NFT data API on Solana, the RPC provider decision comes down to three things: whether the endpoint can sustain your read pattern, whether it exposes the methods you need without silent throttling, and whether you can fail over without breaking in-flight requests.

For most teams, a managed Solana RPC API is the right starting point. You get a maintained endpoint, WebSocket support, and a path to a dedicated node when your indexing or minting workload outgrows shared capacity. OnFinality provides both shared Solana RPC and dedicated node options, so you can start on the shared endpoint and move to a private node without changing your client code.

Use the checklist below to decide whether a shared endpoint is enough or whether you need dedicated infrastructure.

Signal	Shared RPC is likely enough	Move to a dedicated node
Request volume	Bursty, low sustained RPS	Steady high RPS or large `getProgramAccounts` scans
Method mix	Standard account and transaction reads	Heavy `getProgramAccounts`, `getTokenAccountsByOwner`, log subscriptions
WebSocket use	Occasional subscriptions	Continuous `logsSubscribe` or `accountSubscribe` streams
Latency sensitivity	UI reads and background jobs	Mint flows, marketplace settlement, real-time indexing
Isolation needs	No strict tenant isolation	You need predictable capacity and no noisy neighbours

If two or more rows land in the right column, plan for a dedicated node. See Dedicated nodes for how that works.

What NFT data APIs actually ask the RPC to do

An NFT data API is not a single call. It is a pipeline. A typical Solana NFT backend does some combination of:

Resolving token accounts with getTokenAccountsByOwner or getTokenAccountsByMint
Reading metadata accounts, often via getAccountInfo on the Metaplex metadata program
Scanning program-owned accounts with getProgramAccounts, which is the most expensive call in the set
Tracking ownership changes with accountSubscribe or logsSubscribe over WebSocket
Confirming transactions with getTransaction and getSignatureStatuses
Handling compressed NFTs, which add proof and tree lookups on top of the above

Each of these has a different cost profile. getAccountInfo is cheap and cacheable. getProgramAccounts can return thousands of accounts and is the call most likely to hit a provider limit. WebSocket subscriptions are cheap per message but require a stable connection and reconnect logic.

That mix is why a generic "fast RPC" claim is not enough. You need a provider that documents how it handles large account scans and long-lived subscriptions.

Solana RPC methods that matter for NFT workloads

Method	Typical NFT use	Cost profile	Watch for
`getAccountInfo`	Metadata, mint accounts	Low	Cache aggressively
`getTokenAccountsByOwner`	Wallet NFT holdings	Medium	Pagination and large owners
`getTokenAccountsByMint`	Collection holders	Medium	Result size
`getProgramAccounts`	Collection indexing	High	Provider caps and timeouts
`getSignaturesForAddress`	History and provenance	Medium	Pagination depth
`getTransaction`	Transfer and mint detail	Medium	Archive availability
`accountSubscribe`	Ownership changes	Low per message	Reconnect handling
`logsSubscribe`	Mint and sale events	Low per message	Filter design

If your API depends on getProgramAccounts or deep getTransaction history, confirm the provider supports those at your expected volume before you build on it.

Testing a Solana endpoint before you commit

Do not pick a provider from a feature list. Send real requests. Start with a basic health check against the Solana mainnet endpoint:

curl -s https://solana.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getHealth",
    "params": []
  }'

Then test the call that actually stresses your workload. For an NFT indexer, that is usually a program account scan:

curl -s https://solana.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getProgramAccounts",
    "params": [
      "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA",
      { "encoding": "jsonParsed", "filters": [{ "dataSize": 165 }] }
    ]
  }'

Run it repeatedly and watch for three things: response time stability, whether results are truncated, and whether you get rate-limit errors under load. A provider that returns fast once but degrades under repetition is not reliable for an indexer.

For WebSocket subscriptions, test the connection separately:

const ws = new WebSocket("wss://solana.api.onfinality.io/public-ws");

ws.onopen = () => {
  ws.send(JSON.stringify({
    jsonrpc: "2.0",
    id: 1,
    method: "logsSubscribe",
    params: [{ mentions: ["TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA"] }, { commitment: "confirmed" }]
  }));
};

ws.onmessage = (event) => {
  const msg = JSON.parse(event.data);
  if (msg.method === "logsNotification") {
    // route to your NFT event pipeline
  }
};

ws.onclose = () => {
  // implement reconnect with backoff
};

If the socket drops and does not recover cleanly, your indexer will silently miss events. Test reconnect behaviour explicitly.

Provider evaluation matrix for Solana NFT data

Provider	Shared endpoint	Dedicated node option	WebSocket	Archive / history	Notes
OnFinality	Yes, Solana RPC API	Yes	Yes	Confirm current scope on the network page	Managed RPC plus dedicated nodes, same client config
Public cluster endpoints	Yes	No	Limited	Limited	Fine for prototypes, not for indexing
General managed RPC providers	Varies	Varies	Often	Varies	Check method caps and subscription limits
Self-hosted validator or RPC	No	Yes	Yes	Depends on your setup	Highest control, highest ops cost

OnFinality is listed first because it offers both a managed Solana RPC API and dedicated nodes under one account, which removes the migration step when your workload grows. Compare current plans on RPC pricing and check network coverage on supported RPC networks.

Rate limits, caching, and the calls that break first

Most Solana NFT API outages trace back to the same few causes:

Unbounded getProgramAccounts. A scan that returns tens of thousands of accounts will time out or get throttled. Filter by data size, use memcmp filters, and paginate where possible.
Hidden rate limits. Some providers apply per-method caps that are not obvious from the pricing page. Test under realistic concurrency.
WebSocket churn. Long-running subscriptions drop. Without reconnect and backfill logic, you lose events.
Cache misses on metadata. Metadata changes rarely. Cache it and cut your RPC volume significantly.
Commitment mismatch. Reading at processed while writing at confirmed produces inconsistent NFT state. Pick a commitment level and stay consistent.

A simple monitoring probe helps you catch these early:

async function probe() {
  const start = Date.now();
  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: "getHealth", params: [] })
  });
  const latency = Date.now() - start;
  const body = await res.json();
  return { ok: body.result === "ok", latency, status: res.status };
}

Log latency and error rate per method, not just per endpoint. That is what tells you which call is causing trouble.

Failover and multi-provider setup

For production NFT APIs, a single endpoint is a single point of failure. A practical setup is:

One primary managed endpoint for normal traffic
One secondary endpoint from a different provider or region
Health checks that switch traffic when error rate or latency crosses a threshold
A dedicated node for the heaviest workload, such as full collection indexing

Keep the failover logic at the client or gateway level, and make sure both endpoints support the same methods. A failover that lands on an endpoint without getProgramAccounts support is worse than no failover.

If you want to skip the multi-provider complexity, a dedicated Solana node gives you isolated capacity and predictable behaviour. See Dedicated nodes for the tradeoffs.

Key Takeaways

Solana NFT data APIs depend on a specific method mix, and getProgramAccounts plus WebSocket subscriptions are the calls most likely to hit provider limits.
Test providers with real JSON-RPC calls, not feature lists. Check latency stability, result truncation, and rate-limit behaviour under load.
Shared RPC is fine for bursty, low-volume reads. Move to a dedicated node when you run continuous indexing, mint flows, or large account scans.
WebSocket reconnect and backfill logic is mandatory for any event-driven NFT pipeline.
OnFinality offers both managed Solana RPC and dedicated nodes, so you can start shared and scale without changing client code. Start from the Solana network page.

Frequently Asked Questions

Do I need a dedicated node to build an NFT data API on Solana?
Not always. If your workload is bursty and mostly account reads, a shared managed endpoint is enough. Move to a dedicated node when you run continuous indexing, large getProgramAccounts scans, or need predictable capacity.

Why does getProgramAccounts fail on some providers?
It is an expensive call that can return large result sets. Some providers cap result size, apply per-method rate limits, or time out. Always test it at your expected volume before committing.

Is WebSocket support required for NFT indexing?
For real-time ownership and mint tracking, yes. accountSubscribe and logsSubscribe let you react to events instead of polling. Make sure your client handles reconnects and backfills missed slots.

How do I test a Solana RPC provider for NFT workloads?
Send getHealth, then getProgramAccounts with realistic filters, then open a WebSocket subscription and force a reconnect. Measure latency stability and error rate per method.

Where can I see OnFinality's Solana RPC options?
The Solana network page covers the endpoint and transport details, and RPC pricing covers plan options.

Related resources

Originally published at OnFinality.

DEV Community