Polygon
Polygon
Prêt à utiliser cela en production ?
Le niveau gratuit couvre les projets personnels. Le paiement à l'usage évolue sans carte bancaire.
Polygon
Le niveau gratuit couvre les projets personnels. Le paiement à l'usage évolue sans carte bancaire.
TheRPC exposes Polygon PoS through a fully standards-compliant JSON-RPC 2.0 API, so anything you have built against an Ethereum-style node works against chain ID 137 without rewrites. The architecture rests on four pillars: standard HTTP and WebSocket endpoints under polygon.therpc.io, simple API-key authentication, a unified response envelope shared across every method, and cross-network compatibility — the same request shape and the same API key let you point at Polygon today and any other supported chain tomorrow by swapping only the hostname.
The HTTP endpoint is the right choice for single, request-response style calls and simple integrations — reading a MATIC balance, fetching the latest Bor block height, broadcasting a transaction, or running batched reads from a backend service. It is stateless and easy to call from any language or HTTP client. See the HTTP/Curl guide for copy-paste examples against the Polygon endpoint.
The WebSocket endpoint keeps a persistent connection open, which makes it ideal for real-time data and push-based subscriptions. On Polygon, where new blocks land roughly every 2 seconds, WebSockets let you stream fresh heads, watch contract logs from QuickSwap or Aave as they happen, and follow pending transactions without hammering the API with polling. See the eth_subscribe reference for subscription examples.
Every call to the Polygon endpoint is a JSON-RPC 2.0 request carrying four fields. jsonrpc is always the string "2.0"; method names the call, such as eth_blockNumber or eth_getBalance; params is an array of arguments for that method (empty when none are needed); and id is a client-chosen identifier that TheRPC echoes back so you can match each response to its request — especially useful when you batch several Polygon reads together.
Every response from the Polygon endpoint follows the same predictable shape. It always carries jsonrpc set to "2.0" and the same id you sent, and then exactly one of two outcomes: a result field on success, or an error object describing what went wrong. This consistency means a single response-handling path works for every method across the API, whether you are reading a block or tracing a transaction.
Every request to the Polygon endpoint must carry your API key in the Authorization header using the Bearer scheme. The key both authenticates you and ties usage to your plan's Compute Unit allowance and rate limits. For the full walkthrough — generating a key, securing it, and handling auth errors — see the Authentication guide.
The Polygon API splits into two tiers. The standard methods cover everyday work: eth_ for the core protocol (balances, blocks, transactions, contract calls), net_ for network status, and web3_ for utility helpers. The advanced methods unlock deeper inspection: debug_ for replaying and analyzing execution, trace_ for full internal call trees, and txpool_ for inspecting the pending mempool. Each namespace prefix links through to its specific method documentation, with Polygon-tuned examples and Compute Unit costs.
When a Polygon request fails, the error object's code tells you what to fix. The five standard JSON-RPC codes are -32700 for a parse error (malformed JSON), -32600 for an invalid request, -32601 for a method that does not exist, -32602 for invalid parameters (a common cause is a badly formatted address or block tag), and -32603 for an internal error. For detailed handling strategies — retries, backoff, and logging — see the FAQ.
polygon.therpc.io endpoint.requests.