Polygon Public RPC: When to Use It and When to Move On

Is the Polygon public RPC the right endpoint for your workload?

A public RPC is the fastest way to talk to Polygon, but it is a shared resource. Before you paste an endpoint into a config file, match it to the job you are asking it to do.

If you are prototyping, the public endpoint removes all setup friction. If you are shipping to users, treat the public endpoint as a fallback, not the primary path. OnFinality provides both a shared RPC API and dedicated Polygon nodes, so you can start public and upgrade without changing your application logic.

Polygon chain settings you need to connect

Polygon PoS mainnet uses chain ID 137 and the native gas token POL. Keep these values consistent across wallets, libraries, and deployment configs, because a mismatch is one of the most common causes of "wrong network" errors.

For testnet work, Polygon Amoy uses chain ID 80002, the POL token, and the explorer at https://amoy.polygonscan.com. Its public endpoint is https://polygon-amoy.api.onfinality.io/public. See the Polygon network page for the current endpoint list and transport support.

A minimal request against the public endpoint

Start with a read-only call. eth_chainId confirms you are on the right network, and eth_blockNumber confirms the endpoint is responding.

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

A healthy response returns 0x89, which is 137 in hex. If you get a different value, you are pointed at another chain. If you get an HTTP 429 or a JSON-RPC error, the endpoint is rate limiting or temporarily unavailable.

In JavaScript, the same check looks like this with viem:

import { createPublicClient, http } from 'viem'
import { polygon } from 'viem/chains'

const client = createPublicClient({
  chain: polygon,
  transport: http('https://polygon.api.onfinality.io/public')
})

const chainId = await client.getChainId()
const block = await client.getBlockNumber()
console.log({ chainId, block })

For wallet setup, users can add Polygon manually with the values in the table above, or you can prompt them with wallet_addEthereumChain. Keep the RPC URL in one place in your frontend so you can swap it later without hunting through components.

What the public endpoint does well, and where it strains

The public endpoint is a shared gateway. It is excellent for reads, wallet interactions, and development. It is not designed for sustained parallel traffic or heavy log queries.

• Reads and simple writes: eth_call, eth_getBalance, eth_sendRawTransaction, and eth_getTransactionReceipt behave normally.
• Log queries: eth_getLogs over wide block ranges is the first method to get throttled, because it is expensive for the node to serve.
• WebSocket subscriptions: transport support exists, but shared subscriptions can drop under load. Reconnect logic is mandatory.
• Archive data: public endpoints typically serve recent state. Deep historical queries may fail or time out.
• Trace and debug methods: these are usually unavailable or restricted on shared public endpoints.

If your application depends on any of the last three, plan for a managed or dedicated endpoint rather than discovering the limit in production.

Symptoms that mean it is time to move off the public RPC

You do not need a formal capacity plan to know the public endpoint is no longer enough. These signals show up early:

1. Intermittent 429 responses during peak hours, even at modest request rates.
2. Timeouts on eth_getLogs when you widen a block range for a backfill.
3. WebSocket disconnects that your client does not recover from cleanly.
4. Inconsistent latency that makes UI spinners feel random rather than predictable.
5. Missing historical state when a user opens an old transaction or position.
6. No visibility into why a request failed, because shared endpoints rarely expose per-key metrics.

When two or more of these appear, the fix is not a longer retry loop. It is an endpoint with capacity you control.

Moving from public to managed or dedicated Polygon RPC

The migration is usually a configuration change, not a rewrite. Keep the interface identical and change the transport target.

// Before: shared public endpoint
const transport = http('https://polygon.api.onfinality.io/public')

// After: managed endpoint with your own key
const transport = http(process.env.POLYGON_RPC_URL, {
  retryCount: 3,
  retryDelay: 250,
  timeout: 10_000
})

A practical rollout:

1. Put the endpoint in an environment variable so you can change it without a deploy.
2. Run the managed endpoint in staging and compare error rates and latency against the public baseline.
3. Add a fallback provider or a second endpoint for failover.
4. Move read-heavy paths first, then writes, then any archive or trace workloads.
5. Keep the public endpoint as a last-resort fallback, not the default.

If you need predictable throughput, isolated resources, or archive and trace access, dedicated nodes give you a node that is not shared with other customers. If you want managed capacity without operating the node yourself, the RPC API service is the middle path. Compare plans on the RPC pricing page.

Choosing between public, shared, and dedicated endpoints

Use this matrix to match the endpoint type to the workload rather than to a budget line.

OnFinality sits across the shared and dedicated tiers: you can start on the shared RPC API and move to dedicated Polygon infrastructure as traffic grows, keeping the same JSON-RPC interface. For a broader evaluation framework, see how to choose an RPC provider.

Operational checklist before you ship

Even on a managed endpoint, a few habits prevent most incidents:

• Pin the chain ID in your client config so a wrong-network response fails fast.
• Set explicit timeouts and retries rather than relying on library defaults.
• Batch reads where the library supports it to reduce request count.
• Cache immutable data such as confirmed receipts and old logs.
• Monitor error rate and p95 latency per method, not just overall.
• Alert on 429s and WebSocket reconnects, since both precede user-visible failures.
• Keep a fallback endpoint configured and tested, not just documented.

A simple monitoring probe can catch endpoint degradation before users do:

#!/usr/bin/env bash
RPC="${POLYGON_RPC_URL:-https://polygon.api.onfinality.io/public}"
START=$(date +%s%3N)
RESP=$(curl -s -o /dev/null -w "%{http_code}" "$RPC" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}')
END=$(date +%s%3N)
echo "status=$RESP latency_ms=$((END-START))"

Run this on a schedule and record the output. A rising latency trend or a run of non-200 responses is your earliest warning that the current endpoint is no longer sufficient.

Key Takeaways

• The Polygon public RPC at https://polygon.api.onfinality.io/public is a shared endpoint suited to development, wallets, and low-volume scripts.
• Polygon mainnet uses chain ID 137 and POL as the native token; Amoy testnet uses chain ID 80002.
• eth_getLogs, archive queries, trace methods, and heavy WebSocket use are the first workloads to hit shared-endpoint limits.
• Intermittent 429s, timeouts, and WebSocket drops are signals to move to a managed or dedicated endpoint.
• Migration is usually a transport change plus retries, timeouts, and a fallback, not an application rewrite.
• OnFinality offers shared RPC and dedicated Polygon nodes, so you can scale capacity without changing your JSON-RPC interface. See supported RPC networks for coverage.

Frequently Asked Questions

Is the Polygon public RPC free to use?

Public endpoints are generally open for development and light use without an API key. They are shared, so they are not appropriate for production traffic or workloads that need consistent capacity.

What is the Polygon mainnet chain ID?

Polygon PoS mainnet uses chain ID 137. Polygon Amoy testnet uses chain ID 80002. Always confirm the chain ID with eth_chainId before sending transactions.

Why does my Polygon RPC request return HTTP 429?

A 429 means the endpoint is rate limiting your requests. On a shared public endpoint this happens under load. Reduce request frequency, batch reads, or move to a managed endpoint with capacity for your traffic.

Can I use the public RPC for eth_getLogs?

Small block ranges usually work. Wide ranges for indexing or backfills are commonly throttled or time out. Use a managed or dedicated endpoint with archive access for log-heavy workloads.

Does the public endpoint support WebSocket subscriptions?

Transport support exists, but shared subscriptions can disconnect under load. If you rely on eth_subscribe, implement reconnect logic and consider a dedicated endpoint for stability.

When should I switch to a dedicated Polygon node?

Switch when you need predictable throughput, isolated resources, archive or trace access, or per-key visibility into failures. Dedicated nodes remove the shared-capacity variable from your reliability equation.

How do I change the RPC endpoint in my app?

Keep the URL in an environment variable and pass it to your HTTP transport. That way you can move from public to managed or dedicated without touching application code.