Polygon RPCs: How to Pick an Endpoint That Survives Production Traffic

Polygon RPCs are the JSON-RPC endpoints your application calls to read state, send transactions, and subscribe to events on the Polygon PoS network. If you searched for "polygon rpcs," you probably need one of three things: a working endpoint right now, a way to compare endpoints before you commit, or a fix for an endpoint that started misbehaving under load. This page covers all three, starting with the decision that matters most.

Quick recommendation: which Polygon RPC fits your workload

Match the endpoint to what your app actually does, not to what a tutorial used.

If you are still prototyping, a public endpoint is fine. Once real users or real money touch the app, move to a managed RPC API such as OnFinality's RPC service, and consider a dedicated node when your traffic is predictable and heavy.

What a Polygon RPC endpoint actually is

Polygon PoS is an EVM-compatible chain, so its RPC surface is the standard Ethereum JSON-RPC interface. Your client sends a JSON body over HTTP POST (or opens a WebSocket) and gets back a result. The chain ID for Polygon Mainnet is 137, the native currency is POL, and the canonical explorer is polygonscan.com.

A public OnFinality endpoint for Polygon Mainnet looks like this:

https://polygon.api.onfinality.io/public

That URL accepts HTTP and WebSocket traffic. For anything beyond light testing, you would normally use an API key so your traffic is attributed to your account rather than shared capacity.

Chain settings at a glance

Use these values when adding Polygon to a wallet or a client config.

For testnet work, the Amoy endpoint is https://polygon-amoy.api.onfinality.io/public with chain ID 80002 and explorer https://amoy.polygonscan.com. Keep mainnet and testnet configs in separate environment files so a stray chain ID never reaches production.

A minimal wallet or client config in JavaScript:

const polygon = {
  chainId: "0x89", // 137
  chainName: "Polygon Mainnet",
  nativeCurrency: { name: "POL", symbol: "POL", decimals: 18 },
  rpcUrls: ["https://polygon.api.onfinality.io/public"],
  blockExplorerUrls: ["https://polygonscan.com"],
};

Reading and writing: the calls that dominate your traffic

Most Polygon RPC traffic is a small set of methods. Knowing which ones you call most tells you what to optimize.

• eth_chainId and net_version for connectivity checks.
• eth_blockNumber and eth_getBlockByNumber for chain head tracking.
• eth_getBalance, eth_call, and eth_getCode for reads.
• eth_getLogs for event indexing, often the heaviest call.
• eth_sendRawTransaction for writes.
• eth_subscribe over WebSocket for new heads and logs.

A quick connectivity check with curl:

curl -s https://polygon.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

If that returns a hex block number, your endpoint is reachable. If it hangs, the problem is usually network path or endpoint availability, not your payload.

Where Polygon RPCs break under real traffic

Endpoint problems rarely appear in a hello-world test. They show up when concurrency, log ranges, or subscriptions grow.

A simple monitoring probe catches most of these before users do:

async function probe(url) {
  const start = Date.now();
  const res = await fetch(url, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ jsonrpc: "2.0", id: 1, method: "eth_blockNumber", params: [] }),
  });
  const body = await res.json();
  return { ok: res.ok, ms: Date.now() - start, block: body.result };
}

Run this against each endpoint you depend on, log the latency and block height, and alert when a provider falls behind the others.

WebSocket subscriptions and when to use them

Polling eth_blockNumber works, but it wastes requests. If your app needs live updates, open a WebSocket and subscribe:

const ws = new WebSocket("wss://polygon.api.onfinality.io/public");
ws.onopen = () => {
  ws.send(JSON.stringify({
    jsonrpc: "2.0", id: 1,
    method: "eth_subscribe",
    params: ["newHeads"],
  }));
};
ws.onmessage = (event) => console.log(JSON.parse(event.data));

WebSocket connections are stateful, so plan for reconnects, backoff, and duplicate-event handling. If your provider does not support WebSocket, you are stuck polling, which raises request volume and cost.

Evaluating Polygon RPC providers

When you compare providers, compare against your workload, not a generic feature list. OnFinality appears first here because it is the option this page is built around, but the criteria apply to any provider.

Ask each provider the same questions: what is the sustained request rate per plan, is archive data included, are debug and trace methods exposed, how are WebSocket connections counted, and what happens during a chain upgrade or reorg. You can read a fuller framework in how to choose an RPC provider.

Failover and redundancy without over-engineering

A single endpoint is a single point of failure. You do not need a complex mesh, but you do need a fallback.

1. Keep a primary endpoint and one secondary from a different provider or region.
2. Health-check both on a schedule and route to the healthy one.
3. For writes, retry with the same signed transaction rather than re-signing.
4. Log which endpoint served each request so incidents are traceable.
5. Re-test failover after every provider or plan change.

This is enough for most production dApps. Teams with strict uptime needs usually move to a dedicated node so capacity is not shared.

Cost and capacity planning

RPC cost tracks request volume, method weight, and connection count. Reads are cheap; eth_getLogs over wide ranges and archive queries are expensive. Before you scale, estimate your peak requests per second, your average log range, and how many WebSocket clients you keep open. Then pick a plan that leaves headroom, and review RPC pricing against that estimate rather than guessing. If your usage is spiky, a managed API absorbs the peaks better than a fixed-size node.

Key Takeaways

• Polygon RPCs are standard EVM JSON-RPC endpoints; chain ID 137, native currency POL.
• Public endpoints suit testing; production apps should use a keyed managed endpoint.
• eth_getLogs, archive reads, and WebSocket subscriptions are the calls most likely to break under load.
• Compare providers on throughput, archive depth, trace support, WebSocket limits, and failover.
• Keep a secondary endpoint and health-check it before you need it.
• OnFinality offers a managed RPC API and dedicated nodes for Polygon; see supported RPC networks for the current list.

Frequently Asked Questions

What is the Polygon Mainnet RPC endpoint?

OnFinality's public Polygon Mainnet endpoint is https://polygon.api.onfinality.io/public, supporting HTTP and WebSocket. For production, use a keyed endpoint from the Polygon network page.

What chain ID does Polygon use?

Polygon Mainnet uses chain ID 137 (0x89). The Amoy testnet uses 80002.

Do I need an archive node for Polygon?

Only if you query historical state or wide log ranges. Standard reads and recent blocks work on non-archive nodes.

Can I use WebSocket with Polygon RPCs?

Yes. OnFinality's Polygon endpoint supports WebSocket, which is useful for eth_subscribe on new heads and logs.

How do I fix 429 errors from a Polygon RPC?

429 responses mean you hit a rate limit. Move to a keyed managed endpoint, reduce request volume, or batch calls where possible.

When should I use a dedicated Polygon node instead of a shared endpoint?

When your traffic is heavy and predictable, when you need isolated capacity, or when shared rate limits interfere with production. See dedicated nodes.