Nine Calls That Used to Be Ninety: Enhanced APIs Are Live

A wallet balance screen is never one RPC call. It's eth_getBalance, then balanceOf for every token, then decimals() and symbol() for each one — and if you want the numbers to be consistent, you'd better pin them all to the same block. Understanding one transaction is a fetch, a receipt, and a pile of log decoding. Every EVM app rebuilds these same call-groups, badly, on deadline.

As of this week, on SwiftNodes they're one call each. Nine sn_* methods are live on every paid plan, on the same endpoint and key you already use:

One example, live against mainnet:

curl -X POST "https://rpc.swiftnodes.io/rpc/eth?key=YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"sn_getTokenBalances",
       "params":["0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
                 ["0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"]]}'

{ "address": "0xd8da…6045", "blockNumber": "0x18a4058",
  "nativeBalance": "6642178165221340300",
  "tokens": [{ "contract": "0xa0b8…eb48", "balance": "37192124",
               "symbol": "USDC", "decimals": 6 }] }

That's vitalik.eth's actual USDC, with metadata, pinned to one block — one round trip.

The design choices worth knowing

Everything is pinned. Multi-value responses carry a blockNumber, and every value in them was read at that block. The balance-reading traps — mixed-block snapshots, assumed decimals — are handled server-side.

It's batching, not magic. Under the hood each call becomes a single JSON-RPC batch to one upstream — a pattern we could commit to because our method-support matrix verifies weekly that every EVM chain we serve handles batching. sn_getBlockBundle even reads the matrix's reality: it uses eth_getBlockReceipts on chains that support it and falls back to per-transaction assembly where they don't. You could build all of this yourself with Multicall3 and patience — that's the point, you shouldn't have to.

Decoding is honest. sn_getTransactionBundle reports status as success, reverted, or pending, because mined and succeeded are different things. Standard events (Transfer, Approval, the ERC-1155 family) come back with named fields; anything non-standard stays raw rather than guessed at. In yesterday's verification run, a single sn_getBlockBundle on a 183-transaction block returned all 183 receipts with 743 decoded events — one request.

One call counts as one request. This is where we differ from how enhanced APIs are usually sold. Competitors meter their equivalent calls at a premium — an enhanced call burns more compute units than a raw one. Ours count as exactly one request against your rate limit no matter how many values come back, because flat-rate means flat-rate.

Why paid-only

Enhanced APIs are included with every paid plan — Starter and up — and return a clear upgrade error on the free tier. The free tier's job is letting you evaluate raw RPC honestly; the enhanced surface is part of what the flat monthly price buys, alongside unlimited volume, archive access, and this week's other launch, MEV-protected sends.

What's next

The current methods take explicit token lists, because "which tokens does this address hold at all" — and full address transaction history — need an index rather than clever live calls. That indexing layer is in the works; the API shape you see today is designed so those answers slot into it naturally.

Full parameter docs and limits: /docs/enhanced-apis. Plans start at $49/mo, flat — no compute units, no surprises, now with fewer round trips.

Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.