Solana public API endpoints: how do they work and when are they enough?

Solana exposes a public JSON-RPC API for each of its clusters: mainnet, devnet, and testnet. These endpoints are free to use and work well for development, demos, and small experiments, but they are shared infrastructure with rate limits and no production-grade reliability promises. This reference explains the Solana public API endpoints, how to call them, common failure modes, and the criteria for moving to a managed or dedicated Solana RPC service.

Solana public API decision checklist

• Identify your cluster. Public endpoints are cluster-specific: mainnet, devnet, or testnet.
• Assess your traffic. If you expect sustained request volume, a public endpoint may return 429 or 403 responses.
• Check rate limits. Solana documentation lists public endpoint limits, but they can change at any time.
• Confirm required methods. Most JSON-RPC methods are available, but some specialized or archive methods may be limited.
• Evaluate WebSocket needs. Public WebSocket endpoints exist, but they are also shared and can drop subscriptions under load.
• Design for errors. Implement backoff, retry, and caching around public endpoint responses.
• Plan for production. Before mainnet launch, review private RPC or dedicated node options to avoid sharing capacity with other teams.

What is the Solana public API?

The Solana public API is the set of JSON-RPC and WebSocket endpoints operated by Solana Labs for each cluster. Any application can send HTTP requests to these endpoints to read account data, query blocks, simulate transactions, or submit signed transactions. The WebSocket endpoints let you subscribe to account, signature, program, and slot changes.

Public endpoints are a convenient entry point because they require no API key and no setup. However, they are completely shared. That means a spike from one dApp can degrade the experience for every other consumer on the same endpoint. For this reason, the Solana docs explicitly describe the public endpoints as acceptable for development, early demos, and small private beta programs, but not for production applications.

The query "solana public api" usually arrives from two directions: developers who need the exact endpoint URLs and configuration values, and teams deciding whether a public endpoint is enough for their workload. This article covers both.

Solana clusters and public API endpoints

Solana operates several clusters, each with its own ledger, token, and set of validators. Every RPC request goes to a specific cluster, so the endpoint you choose determines which network state you read and where transactions are sent.

For local development, the solana-test-validator binary runs a validator on your machine and exposes a local HTTP RPC endpoint at http://localhost:8899 and a WebSocket endpoint at ws://localhost:8900.

Public endpoints are not the only option. Many RPC providers, including OnFinality, offer managed Solana API endpoints with predictable limits, as well as dedicated Solana nodes for teams that need isolated capacity. A managed endpoint can support the same JSON-RPC interface as the public API while adding private infrastructure and operational support.

How to call the Solana public API

The public API follows the standard JSON-RPC 2.0 specification. You send an HTTP POST request with a jsonrpc, id, method, and optional params array. The response contains a jsonrpc, id, and result or error object.

The following curl example calls the getSlot method on mainnet with a finalized commitment. Commitment controls how finalized a block must be before the node returns data; it is one of the most important parameters in Solana RPC calls.

curl https://api.mainnet.solana.com -H "Content-Type: application/json" -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getSlot",
  "params": [
    {
      "commitment": "finalized"
    }
  ]
}'

A successful response looks like this:

{
  "jsonrpc": "2.0",
  "result": 312345678,
  "id": 1
}

For WebSocket subscriptions, connect to the WebSocket URL for the cluster and send a subscription request, such as accountSubscribe or slotSubscribe. The public WebSocket endpoints are also free to use, but they may disconnect idle clients or apply their own rate limits.

Rate limits and common public endpoint errors

Public Solana API endpoints are rate limited to protect the shared infrastructure. The exact limits are documented in the Solana cluster reference, but they are subject to change without notice. Two HTTP status codes appear frequently:

• 429 Too Many Requests: You have exceeded the rate limit for the endpoint.
• 403 Forbidden: The request was blocked, often by a Web Application Firewall, due to suspicious traffic patterns or abuse.

These errors are not bugs in your code; they are the public API telling you that its shared capacity has been exhausted. If your application does not handle them, you will see intermittent failures that are difficult to reproduce.

To work around rate limits on the public API, you can reduce request frequency, cache expensive calls such as getProgramAccounts and getSignaturesForAddress, and use batch requests where possible. However, those techniques only reduce load; they do not remove the fundamental problem of sharing capacity with everyone else.

When to move beyond the public API

A production dApp on Solana mainnet should not depend on the public API for several reasons:

• No capacity guarantees: Your requests compete with every other user.
• Rate limit changes: You may find your application breaking when limits are adjusted.
• Limited archive depth: The public API is not an archive node, so historical access may not be available for all slots.
• No dedicated WebSocket capacity: Live data feeds can be dropped under load.
• No support contract: You have no one to contact if the endpoint is unavailable.

At this point, teams typically evaluate a managed RPC service or a dedicated node. A managed service gives you a private endpoint with defined request limits, while a dedicated node gives you isolated compute and bandwidth. Both approaches remove the noisy-neighbor problem and provide a more stable foundation for production traffic.

OnFinality is one of the providers that offers both options. You can request a public Solana endpoint through the service, access higher-tier capacity on a managed RPC API, or provision a dedicated Solana node for complete isolation. For a complete list of supported chains, see the supported RPC networks page.

How to evaluate Solana public API alternatives

When you compare Solana API providers, the surface area is larger than a single latency number. The right choice depends on your traffic pattern, data requirements, and budget. The table below summarizes the criteria that matter for most Solana teams.

If you are already using the public API and only need a small amount of additional headroom, a shared managed RPC endpoint is usually the easiest next step. If you need to guarantee response latency or run heavy indexing, a dedicated node may be more appropriate. You can review both approaches on the RPC pricing page.

Production tips for Solana RPC clients

Even with a private RPC endpoint, the way you build your client has a large impact on performance and cost.

• Use the correct commitment level. processed is the newest but can reorg; confirmed is safer; finalized is the slowest but canonical. Do not default to finalized for every read if your application tolerates slight reorgs.
• Cache expensive calls. getProgramAccounts and getSignaturesForAddress are expensive for Solana nodes. Serve them from a cache whenever possible.
• Batch independent requests. Many JSON-RPC calls can be batched into one HTTP request, reducing round trips and rate limit consumption.
• Prefer WebSocket subscriptions over polling. Subscriptions reduce the number of request-response calls and keep state fresh.
• Handle retries gracefully. Use exponential backoff on transient errors like 429 or 503, but avoid retry storms that amplify load.
• Monitor response times. Track your RPC latency and error rate so you notice when a provider or a specific region degrades.

These optimizations are even more important on the public API, where every wasted call competes with the rest of the ecosystem.

Key Takeaways

• The Solana public API is a free JSON-RPC and WebSocket endpoint for mainnet, devnet, and testnet.
• Public endpoints are useful for development, demos, and early testing, but they are shared and rate limited.
• Common public API errors are HTTP 429 (rate limited) and HTTP 403 (blocked traffic), both of which require client-side handling.
• Production workloads should evaluate managed RPC or dedicated nodes for predictable capacity, archive access, and operational support.
• When choosing a provider, compare endpoint type, request limits, WebSocket coverage, cluster support, method availability, and cost model.

Frequently Asked Questions

Is the Solana public API free?

Yes, the Solana Labs public RPC endpoints are free to use. They are shared infrastructure, so they have rate limits and no production uptime guarantee.

What is the difference between the Solana public API and a private RPC endpoint?

A private RPC endpoint is dedicated to your application or a small group of customers, providing more predictable capacity and often additional features like archive data and WebSocket support.

Which Solana public API endpoint should I use for development?

Use https://api.devnet.solana.com for development and testing. You can obtain Devnet SOL from the Solana faucet to pay for transaction fees.

Can I use the public API for a production dApp?

The Solana documentation advises against using public endpoints for production traffic. They are designed for development and early testing, not for sustained production load.

Does OnFinality provide a Solana public API?

OnFinality provides managed Solana RPC endpoints and dedicated node infrastructure. You can get started with a Solana endpoint on the Solana network page and review capacity options on the RPC pricing page.