What should I know about Polygon PoS endpoints?

Polygon PoS is one of the busiest EVM chains, and most teams reach it through a JSON-RPC endpoint rather than running their own node. The tricky part is not finding a URL — it is picking one that matches your workload, wiring it into wallets and backend services correctly, and knowing what to check when calls start failing.

This page is written for developers and infrastructure buyers who need working Polygon PoS endpoints plus the context to choose between a shared public URL and dedicated capacity. If you want the network overview first, see the Polygon RPC page.

Chain settings at a glance

Before you connect anything, confirm the values below. Polygon migrated its native gas token from MATIC to POL, so older tutorials that still reference MATIC can cause confusion in wallet configs and gas estimation.

A public OnFinality endpoint for mainnet is available at https://polygon.api.onfinality.io/public, and the Amoy testnet endpoint is https://polygon-amoy.api.onfinality.io/public. Public endpoints are shared, so treat them as a starting point for development and low-volume reads rather than the final home for a high-traffic production app.

When a shared endpoint is enough — and when it is not

This is the decision most teams get wrong. A shared public endpoint is fine when your call volume is modest, your requests are mostly reads, and occasional latency variance will not break user experience. It becomes a liability when you need predictable throughput, isolated capacity, or long-running subscriptions.

Use this quick fit check:

If you are unsure where you land, start on a shared endpoint, measure your request patterns, and move to dedicated nodes once you can describe your peak load. For a broader framework, the RPC provider selection guide walks through the evaluation criteria.

Connecting from code

The simplest way to confirm an endpoint works is a raw JSON-RPC call. This checks connectivity and returns the current block number:

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

A successful response looks like {"jsonrpc":"2.0","id":1,"result":"0x..."}. If you get a timeout or a non-200 status, the endpoint or your network path is the problem — not your application logic.

In JavaScript, most teams use viem or ethers. 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 block = await client.getBlockNumber();
console.log('Polygon PoS head:', block);

For real-time work, Polygon PoS supports WebSocket subscriptions. A minimal eth_subscribe over wss looks like this:

import WebSocket from 'ws';

const ws = new WebSocket('wss://polygon.api.onfinality.io/public/ws');

ws.on('open', () => {
  ws.send(JSON.stringify({
    jsonrpc: '2.0',
    id: 1,
    method: 'eth_subscribe',
    params: ['newHeads'],
  }));
});

ws.on('message', (data) => {
  console.log('New head:', data.toString());
});

WebSocket availability depends on the endpoint and plan you use. If subscriptions are part of your design, confirm transport support before you commit, because not every shared endpoint exposes wss.

Adding Polygon PoS to a wallet

Wallet and network configs are a common source of "wrong chain" errors. The fields below match the values in the settings table:

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

Note that 0x89 is the hex form of decimal 137. Mixing the two formats is one of the most frequent causes of failed wallet_addEthereumChain calls.

Methods, limits, and what tends to break

Polygon PoS is EVM-compatible, so the standard method set applies: eth_call, eth_getBalance, eth_getLogs, eth_getTransactionReceipt, eth_estimateGas, eth_sendRawTransaction, and so on. The failures you are most likely to hit are not exotic:

• Rate limiting on shared endpoints. Bursty eth_getLogs scans or polling loops can trip shared limits. Batch and cache where possible.
• eth_getLogs range limits. Providers cap the block range per query. If your indexer scans large ranges in one call, split it into chunks.
• Reorg handling. Polygon PoS can reorg, so confirmations matter. Do not treat a single receipt as final for value-bearing logic.
• Archive gaps. Historical eth_call against old blocks needs archive data. Shared endpoints may not serve deep history.
• WebSocket drops. Long-lived subscriptions need reconnect logic with backoff and a resubscribe step.

Debug path for failing calls

When a call fails, work through this order rather than guessing:

1. Reproduce with curl. If the raw request fails, the issue is the endpoint or network, not your SDK.
2. Check the chain ID. Call eth_chainId and confirm you get 0x89 on mainnet.
3. Isolate the method. Test the specific method that fails. A working eth_blockNumber does not prove eth_getLogs will succeed.
4. Inspect the error body. JSON-RPC errors carry codes and messages — rate-limit, method-not-found, and range errors look different.
5. Compare endpoints. If a second endpoint succeeds, the first is the problem.
6. Check timing. Spikes that correlate with your own deploy or cron jobs usually point to request volume, not the provider.

Choosing between shared and dedicated capacity

If your debug path keeps landing on rate limits, range caps, or subscription drops, the fix is capacity, not code. OnFinality offers Polygon PoS through a shared RPC API service and through dedicated node deployments that give your workload isolated resources. Dedicated nodes are the usual choice for indexers, exchanges, and apps with steady production traffic.

When comparing providers, look at the same dimensions regardless of vendor:

Pricing for shared and dedicated options is on the RPC pricing page, and you can browse other chains on the supported RPC networks list.

Key Takeaways

• Polygon PoS mainnet uses chain ID 137 (0x89), native token POL, and explorer polygonscan.com.
• OnFinality public endpoints: https://polygon.api.onfinality.io/public for mainnet and https://polygon-amoy.api.onfinality.io/public for Amoy testnet.
• Shared endpoints suit development and light reads; dedicated nodes suit production traffic, indexers, and subscriptions.
• Most failures trace back to rate limits, eth_getLogs range caps, reorg handling, or WebSocket drops — not to the chain itself.
• Always confirm transport support and archive access before committing to an endpoint for a production workload.

FAQ

What is the Polygon PoS chain ID? Mainnet is 137, written as 0x89 in hex. The Amoy testnet is 80002.

What is the Polygon PoS native token? POL, with 18 decimals. It replaced MATIC as the network's gas and staking token.

Can I use a public endpoint in production? You can, but shared endpoints are subject to contention. For steady traffic, subscriptions, or bulk log queries, a dedicated node gives you isolated capacity.

Does Polygon PoS support WebSocket subscriptions? Yes, the network supports eth_subscribe, but the endpoint you use must expose wss. Confirm transport support for your chosen plan.

Why does eth_getLogs fail on large ranges? Providers cap the block range per query to protect shared infrastructure. Split large scans into smaller chunks and paginate.

How do I switch endpoints without downtime? Run at least two endpoints and fail over when health checks fail. A simple probe that calls eth_blockNumber on a schedule is enough to detect a degraded endpoint.