Solana RPC API Guide: Methods, WebSocket & Commitment

JSON-RPC request and response structure

Solana RPC uses the JSON-RPC 2.0 protocol over HTTPS for request-response calls. A request includes jsonrpc, id, method, and params; a successful response returns the same id and a result, while errors contain an error object with code and message. Most methods require a base58-encoded public key or a transaction signature as a parameter.

The public cluster endpoints are stable and documented: mainnet https://api.mainnet-beta.solana.com and devnet https://api.devnet.solana.com. Testnet also exists; Devnet is the preferred environment for development and testing because it uses test SOL from the official faucet at https://faucet.solana.com. The OnFinality Solana network page lists an HTTPS endpoint and WebSocket endpoint; current plan details and regions should be verified in the documentation.

• Use HTTP POST for request-response methods.
• Set Content-Type: application/json.
• Check the error object in responses for RPC-specific failures.

Accounts and program methods

Account queries are the foundation for most Solana dApps. getAccountInfo returns the account state, owner, lamports, and executable flag; getBalance returns the lamport balance; getMultipleAccounts fetches multiple accounts efficiently.

getProgramAccounts returns all accounts owned by a program. It is one of the most resource-intensive Solana RPC methods, so always include filters for dataSize or memcmp to limit the result set. Otherwise you may time out or hit provider limits.

• getAccountInfo – full account metadata for one address
• getBalance – lamport balance
• getMultipleAccounts – batch account reads
• getProgramAccounts – accounts owned by a program, filtered by size or content

Blocks, slots, and historical data

Solana produces slots; a block is created only when the slot has a leader and transactions. getSlot returns the current slot, getBlock returns a block by slot, and getBlocks returns a range of slots. getBlockHeight returns the latest block height.

For historical transaction data, getSignaturesForAddress returns confirmed signatures for an address, and getTransaction fetches the full transaction by signature. If you need deep history, confirm that your provider has archive support. The OnFinality Solana network page lists archive support for mainnet; availability may depend on your plan, so check current documentation before relying on it.

Transaction simulation, submission, and confirmation

The transaction lifecycle has four steps: fetch a recent blockhash, build and sign the transaction, optionally simulate, then submit. getLatestBlockhash returns the blockhash and last valid block height; simulateTransaction runs the transaction without broadcasting, which reveals errors and consumed compute units.

sendTransaction submits a signed transaction and returns a signature if the RPC accepts it. Confirm finality with getSignatureStatuses or a signatureSubscribe WebSocket subscription. For development, use devnet test SOL from the faucet; see the Solana devnet guide for a walkthrough.

• 1. Call getLatestBlockhash
• 2. Build and sign transaction with your keypair
• 3. Test with simulateTransaction
• 4. Submit with sendTransaction
• 5. Confirm with getSignatureStatuses or signatureSubscribe

WebSocket subscriptions for real-time updates

WebSocket subscriptions are more efficient than polling. Connect to a WebSocket endpoint (e.g., wss://api.mainnet-beta.solana.com) and send a JSON-RPC subscribe request. The server pushes notifications until you send an unsubscribe request or close the connection.

Common subscriptions include accountSubscribe for account changes, logsSubscribe for program logs, programSubscribe for program-owned account changes, signatureSubscribe for transaction confirmations, and slotSubscribe for new slots. Always include a commitment level in the subscription request to control how recent the data must be.

• accountSubscribe – account data changes
• logsSubscribe – program logs
• programSubscribe – program-owned account updates
• signatureSubscribe – transaction confirmation
• slotSubscribe – new slot notifications

Commitment levels and consistency

For wallet balances and transaction confirmations, confirmed is often sufficient. For archival or accounting data, use finalized to avoid reorgs. Some methods like getSlot and getLatestBlockhash accept commitment; always specify it to avoid defaults.

Production API checklist

Before moving to production, verify that your RPC endpoint covers the methods, transports, and regions your product needs. Check the OnFinality Solana network page for current endpoint details, regions, archive support, and WebSocket availability; plan terms can change, so cross-check the documentation. For access setup, see the Solana access guide.

For provider evaluation, see Best Solana RPC provider.

• Test the exact request patterns your frontend and backend will use.
• Confirm WebSocket access if you use subscriptions.
• Check archive support if you need historical data beyond recent slots.
• Verify rate limits and upgrade paths for sustained traffic.
• Use devnet for staging and test SOL from the official faucet.
• Monitor error rates, latency, and usage before full rollout.

Frequently Asked Questions