Summary
An RPC URL is the HTTP or WebSocket address your application uses to send JSON-RPC requests to a blockchain node. It is the connection string that lets wallets, dApps, scripts, and backend services read chain state, submit transactions, and subscribe to events. The URL itself is only half of the configuration: you also need the correct chain ID, currency symbol, and block explorer for wallet setup, and you need to understand which methods and workloads the endpoint supports before you rely on it in production.
This page explains what an RPC URL is, how to choose between public and managed endpoints, and how to wire one into common tools. It also covers the failure modes that show up when an RPC URL is wrong, rate-limited, or missing archive data, and it points to where you can find endpoints for supported networks and dedicated node options when shared public URLs are no longer enough.
Key Takeaways
- An RPC URL is the endpoint your app calls to read and write blockchain data over JSON-RPC.
- Public RPC URLs are fine for prototyping and wallet setup but usually lack the rate limits, archive data, and WebSocket support production apps need.
- Wallet configuration needs more than a URL: chain ID, currency symbol, and explorer URL must match the network.
- Most RPC URL errors come from wrong chain IDs, expired API keys, rate limits, or missing archive/trace methods.
- Managed RPC services and dedicated nodes give you predictable capacity and support when shared endpoints become a bottleneck.
- OnFinality provides RPC API access and dedicated node infrastructure across supported networks; check the network page for exact endpoints and features.
RPC URL meaning in one minute
RPC stands for remote procedure call. In blockchain development, an RPC URL is the address of a node that accepts JSON-RPC requests. Your code sends a request such as eth_blockNumber or eth_getBalance to that URL, and the node returns the result. The same URL can also accept WebSocket connections if the provider supports subscriptions.
A typical RPC URL looks like https://provider.example.com/v1/<api-key> or wss://provider.example.com/ws. The scheme tells you whether it is HTTP or WebSocket, the host points to the provider or your own node, and the path often contains an API key or project ID. Treat the full URL as a secret when it includes a key: anyone who has it can consume your quota.
- HTTP RPC URL: used for request/response calls such as reading balances, sending transactions, and querying logs.
- WebSocket RPC URL: used for subscriptions such as new blocks, pending transactions, and contract events.
- Chain ID: not part of the URL, but required by wallets and many SDKs to confirm which network the endpoint serves.
Public, managed, or dedicated: which RPC URL fits your workload
The right RPC URL depends on who is using it and what happens when it fails. A public endpoint is convenient for a quick script or a wallet configuration, but it is shared with many other users and may not support archive queries, trace methods, or WebSocket subscriptions. A managed RPC service gives you a keyed endpoint with documented limits and support. A dedicated node gives you isolated infrastructure when you need predictable capacity or custom configuration.
Use the table below to match your workload to the type of endpoint. If you are unsure, start with a managed endpoint and move to a dedicated node when you can measure consistent pressure on rate limits or when you need archive data that shared endpoints do not provide.
| Criterion | What to check | Why it matters |
|---|---|---|
| Prototyping and scripts | Public RPC URL or free tier of a managed service | Low setup cost and no commitment while you validate the idea |
| Wallet and dApp configuration | Stable managed endpoint with documented chain ID and explorer | Users need a reliable URL that does not change unexpectedly |
| Production dApp traffic | Managed RPC plan with rate limits, archive access, and WebSocket support | Shared public endpoints can throttle or drop requests under load |
| Indexers and analytics | Archive node access and eth_getLogs limits | Historical queries fail on pruned nodes or endpoints with strict log limits |
| High-volume or latency-sensitive systems | Dedicated node with isolated resources | Isolation reduces noisy-neighbor effects and gives you control over upgrades |
Chain settings at a glance
When you add a network to a wallet or configure an SDK, the RPC URL is only one field. The chain ID must match the network, or transactions will be signed for the wrong chain. The currency symbol is used for display, and the block explorer URL helps users verify transactions. For EVM networks, these values are standardized per chain; for non-EVM networks, the configuration model differs and you should follow the network-specific documentation.
The table below shows the fields most wallets ask for. Always confirm the values against the official network documentation or the OnFinality network page before saving a configuration.
| Criterion | What to check | Why it matters |
|---|---|---|
| RPC URL | HTTP endpoint from your provider or node | The address your wallet or app uses for JSON-RPC calls |
| Chain ID | Numeric chain ID for the network | Prevents transactions from being signed for the wrong chain |
| Currency symbol | Native gas token symbol | Used by wallets to display balances and fees |
| Block explorer URL | Official explorer for the network | Lets users inspect transactions and addresses |
Connecting an RPC URL in code
Most JavaScript libraries accept an RPC URL as a string. The example below uses a generic placeholder because the exact endpoint depends on the network and provider you choose. Replace the placeholder with the HTTP RPC URL from your provider or your own node, and keep API keys in environment variables rather than source control.
For read-only calls, a single HTTP provider is often enough. For applications that need event subscriptions, use a WebSocket URL and handle reconnects. If you use ethers or viem, the provider abstraction handles JSON-RPC formatting, but it does not hide rate limits or method restrictions.
- Store the RPC URL in an environment variable such as RPC_URL.
- Use a separate WebSocket URL for subscriptions if your provider offers one.
- Log JSON-RPC error codes and messages so you can distinguish rate limits from invalid requests.
- Set request timeouts and retries with backoff for transient network errors.
Debug path: common RPC URL failures
When an RPC URL stops working, the symptom usually points to a specific cause. A 401 or 403 response often means the API key is missing, expired, or restricted by origin. A 429 response means you hit a rate limit. A method-not-found error means the endpoint does not support that JSON-RPC method, which is common for archive or trace calls on shared endpoints. A chain ID mismatch shows up as transactions failing or balances appearing empty in a wallet.
Work through the symptoms in order. First confirm the URL is reachable with a simple curl request. Then check authentication, rate limits, method support, and finally chain configuration. If the endpoint is a public URL, assume it may be rate-limited or deprecated without notice and move to a managed endpoint for anything beyond testing.
| Criterion | What to check | Why it matters |
|---|---|---|
| 401 or 403 | API key present, correct, and allowed for this origin | Authentication failures block every request |
| 429 | Request rate and plan limits | Rate limits cause intermittent failures under load |
| Method not found | Archive, trace, or debug method support | Shared endpoints often disable expensive methods |
| Wrong balances or failed transactions | Chain ID and network configuration | A mismatched chain ID points the app at the wrong network |
| Timeouts | Endpoint health and network path | Slow or unreachable nodes break user flows |
When to move from a public RPC URL to managed infrastructure
Public RPC URLs are useful for learning and quick tests, but they are not designed for production traffic. As your application grows, you will likely need higher request limits, archive data for historical queries, WebSocket subscriptions, and a support channel when something breaks. A managed RPC service provides these features with a keyed endpoint and documented limits. A dedicated node goes further by isolating resources for your workload.
OnFinality provides RPC API access and dedicated node infrastructure across supported networks. You can review supported networks to find the endpoint and feature set for your chain, compare RPC pricing for request volume and archive access, and choose dedicated nodes when you need isolated capacity. The right choice depends on your request patterns, data requirements, and how much operational control you want.
- Move to a managed endpoint when you see repeated 429 responses or need archive methods.
- Consider a dedicated node when you need predictable throughput or custom node configuration.
- Check the network page for chain-specific settings and supported methods before migrating.
- Keep a fallback RPC URL configured so a single endpoint failure does not take down your app.
Frequently Asked Questions
What is an RPC URL in simple terms?
An RPC URL is the web address of a blockchain node that your app calls to read data or send transactions. It works like an API endpoint: you send a JSON-RPC request to the URL and receive a response.
Is an RPC URL the same as an API key?
No. The RPC URL is the address of the endpoint. An API key is a credential that may be included in the URL path or sent as a header. Some public endpoints require no key, while managed services usually issue a key to track usage and enforce limits.
Can I use a public RPC URL in production?
Public RPC URLs are best for testing and low-volume use. They are often shared, rate-limited, and may not support archive or WebSocket methods. For production, use a managed RPC service or a dedicated node with documented limits and support.
Why does my wallet say the RPC URL is invalid?
Common causes include a missing or expired API key, an HTTP URL where a WebSocket URL is required, a typo in the host or path, or a chain ID that does not match the network. Verify the URL with a simple curl request and confirm the chain settings against the official network documentation.
How do I find the RPC URL for a specific network?
Check the network's official developer documentation or the OnFinality supported networks page. For EVM networks, chain ID and explorer details are usually listed alongside the RPC URL. Avoid copying endpoints from unofficial sources without verifying them.
Ethereum
Solana
Polygon
Base
Arbitrum
BNB Chain
Polkadot
Optimism
