solana.io: The Solana RPC Endpoint Developers Need

What solana.io is, and what it is not

If you typed solana.io into a browser or a config file expecting a Solana RPC endpoint, you have hit a naming collision. The domain solana.io is not the canonical Solana developer portal, and it is not a JSON-RPC endpoint you can POST requests to. The Solana network is accessed through RPC providers that expose HTTP and WebSocket endpoints, and the official developer documentation lives on the Solana docs site rather than a .io domain.

The practical takeaway: stop looking for solana.io as an endpoint. What you actually need is a Solana mainnet or devnet RPC URL, the right transport (HTTP for request/response, WebSocket for subscriptions), and a decision about whether a shared public endpoint is enough or whether your workload needs dedicated capacity.

This article answers that directly, then walks through connection settings, a working request, and the failure modes that show up when a Solana endpoint is not sized for your traffic.

Which Solana endpoint should you point at?

Before copying any URL, match the endpoint to the environment and the workload. The table below is the fastest way to decide.

Your situation	Environment	Transport	Recommended access
First script, learning JSON-RPC	Devnet	HTTP	Public devnet endpoint
Wallet or dApp testing	Devnet	HTTP + WebSocket	Public or shared endpoint
Production dApp reads	Mainnet	HTTP	Shared or dedicated RPC
Real-time account or slot updates	Mainnet	WebSocket	Endpoint with WS support
High request volume or indexing	Mainnet	HTTP + WebSocket	Dedicated node
Latency-sensitive trading or bots	Mainnet	HTTP + WebSocket	Dedicated node, co-located

Two rules keep you out of trouble. First, never point production traffic at a devnet endpoint, and never point tests at mainnet. Second, if your app opens WebSocket subscriptions, confirm the endpoint advertises WebSocket support before you ship.

OnFinality exposes Solana mainnet over both HTTP and WebSocket, so the same provider can cover request/response calls and subscription-based flows. You can review the network details on the Solana RPC network page, and use Solana Devnet while you are still building.

Solana chain settings at a glance

When you configure a wallet, a framework, or a custom client, these are the values that matter for Solana mainnet.

Setting	Value
Chain name	Solana Mainnet
Native currency	SOL (9 decimals)
HTTP RPC	https://solana.api.onfinality.io/public
WebSocket RPC	wss://solana.api.onfinality.io/public-ws
Block explorer	https://explorer.solana.com

Note that Solana does not use an EVM-style numeric chain ID in the same way Ethereum networks do. If a tool asks for a chain ID, check that tool's Solana-specific documentation rather than guessing a number.

For devnet work, keep your devnet and mainnet configuration in separate environment variables so a copy-paste mistake cannot send test transactions to mainnet.

# .env
SOLANA_MAINNET_RPC=https://solana.api.onfinality.io/public
SOLANA_MAINNET_WS=wss://solana.api.onfinality.io/public-ws
SOLANA_DEVNET_RPC=<your-devnet-endpoint>

A working Solana JSON-RPC request

Solana uses JSON-RPC over HTTP. The example below fetches the current slot, which is a lightweight way to confirm your endpoint is reachable and returning data.

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

A healthy response looks like a JSON object with a result field containing a number. If you get an error object instead, jump to the debugging section below.

The same call in JavaScript with fetch:

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: "getSlot",
    params: [{ commitment: "confirmed" }],
  }),
});

const data = await res.json();
console.log(data.result);

Once basic calls work, move to the methods your app actually needs: getAccountInfo for balances and account data, getTransaction for confirmation checks, sendTransaction for writes, and getProgramAccounts for program-scoped queries. getProgramAccounts is the method most likely to expose an underpowered endpoint because it can return large result sets.

Public endpoint or dedicated node?

This is the decision that determines whether your app stays responsive as usage grows. A public or shared endpoint is fine for development, low-volume scripts, and early testing. A dedicated node makes sense when your traffic is predictable but heavy, when you need consistent access to WebSocket subscriptions, or when you are running indexers and bots that issue many concurrent calls.

Signals that you have outgrown a shared endpoint:

• You see intermittent 429 responses during peak hours.
• WebSocket subscriptions drop and reconnect frequently.
• getProgramAccounts or large getTransaction batches time out.
• Your p95 latency varies widely across the day.
• You need predictable capacity for a launch or a trading window.

If two or more of those apply, evaluate dedicated capacity. OnFinality offers dedicated nodes for teams that need isolated resources, and you can compare access tiers on the RPC pricing page. For a broader framework covering archive access, trace methods, and failover, see how to choose an RPC provider.

Debug path for common Solana RPC failures

When a call fails, the error usually points to one of a few causes. Work through this table before changing providers.

Symptom	Likely cause	Next step
429 Too Many Requests	Rate limiting on a shared endpoint	Reduce concurrency or move to dedicated capacity
Method not found	Method not enabled on that endpoint	Confirm method support with the provider
Timeout on getProgramAccounts	Large result set, endpoint limits	Add filters, paginate, or use a stronger endpoint
WebSocket disconnects	Subscription limits or network instability	Add reconnect logic, confirm WS support
Blockhash not found	Stale blockhash in a transaction	Fetch a fresh blockhash before signing
Empty result for an account	Wrong commitment level or account not yet created	Retry with confirmed or finalized

Two debugging habits pay off. First, log the raw JSON-RPC error object, not just the HTTP status, because Solana returns useful error codes in the body. Second, test the same call against a second endpoint to separate an application bug from an endpoint problem.

If you are chasing rate-limit and authentication issues specifically, the Solana RPC access article goes deeper on those failure modes.

Commitment levels and why they change results

Solana lets you choose how finalized a response must be. This affects both correctness and latency.

• processed returns the fastest but least settled data.
• confirmed is a common default for user-facing reads.
• finalized is the safest for anything irreversible, such as crediting a deposit.

A frequent bug is reading a balance at processed and treating it as final. For anything that moves value, read at confirmed or finalized, and be explicit about the commitment in every call rather than relying on a default.

Running subscriptions over WebSocket

Real-time features such as watching an account or tracking slots need a WebSocket connection. Solana exposes subscription methods like accountSubscribe and slotSubscribe over the WebSocket transport.

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

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

ws.onmessage = (event) => {
  console.log(JSON.parse(event.data));
};

Production subscription code should include reconnect logic with backoff, a heartbeat to detect dead connections, and a cap on the number of simultaneous subscriptions per client. Dropped subscriptions that silently stop delivering updates are one of the hardest bugs to notice, so monitor message arrival rather than assuming the socket is healthy.

Key Takeaways

• solana.io is not the Solana RPC endpoint or the official developer portal; use a real JSON-RPC URL instead.
• Solana mainnet is reachable over HTTP at https://solana.api.onfinality.io/public and over WebSocket at wss://solana.api.onfinality.io/public-ws.
• Match the endpoint to the environment: devnet for building, mainnet for production, and never mix the two.
• Choose commitment levels deliberately; use confirmed or finalized for anything that moves value.
• Move from shared to dedicated capacity when you see sustained 429s, dropped subscriptions, or timeouts on large queries.
• Log raw JSON-RPC error bodies and test against a second endpoint to separate app bugs from endpoint limits.

Frequently Asked Questions

Is solana.io the official Solana RPC endpoint?

No. solana.io is not a JSON-RPC endpoint. Solana is accessed through RPC providers that expose HTTP and WebSocket URLs, and the official developer documentation lives on the Solana docs site.

What is the Solana mainnet RPC URL?

OnFinality exposes Solana mainnet over HTTP at https://solana.api.onfinality.io/public and over WebSocket at wss://solana.api.onfinality.io/public-ws. You can review the network on the Solana RPC network page.

Do I need a WebSocket endpoint for Solana?

Only if your app uses subscriptions such as accountSubscribe or slotSubscribe. If you only make request/response calls, HTTP is enough. If you need real-time updates, confirm the endpoint supports WebSocket before shipping.

When should I move off a public Solana endpoint?

When you see sustained rate-limit errors, dropped WebSocket subscriptions, or timeouts on large queries like getProgramAccounts. At that point, evaluate dedicated nodes and compare tiers on the RPC pricing page.

How do I test a Solana endpoint quickly?

Send a getSlot request with curl as shown above. A numeric result confirms the endpoint is reachable and responding; an error object tells you to check the method, commitment, or rate limits.

Where can I see all the networks OnFinality supports?

The full list is on the supported RPC networks page, including Solana mainnet and devnet.

Next steps

Start by pointing a test script at the Solana mainnet endpoint and confirming a getSlot response. Then add the methods your app needs, set explicit commitment levels, and add WebSocket reconnect logic if you use subscriptions. When your traffic grows past what a shared endpoint handles comfortably, review dedicated nodes and RPC pricing, and keep the supported RPC networks page handy as you expand to other chains.

Related resources

• Solana RPC network
• Solana Devnet RPC
• RPC pricing
• Supported RPC networks
• How to choose an RPC provider
• Dedicated nodes

Originally published at OnFinality.