Avalanche
Avalanche
Bereit, das in der Produktion aufzurufen?
Das Free-Tier deckt persönliche Projekte ab. Pay-as-you-go skaliert ohne Karte.
Avalanche
Das Free-Tier deckt persönliche Projekte ab. Pay-as-you-go skaliert ohne Karte.
TheRPC exposes the Avalanche C-Chain through the JSON-RPC 2.0 specification, the same standard the chain's underlying EVM client speaks, so anything that works against a generic Avalanche node works here unchanged. The API is built around four characteristics: standard HTTP and WebSocket endpoints at avalanche.therpc.io, API-key authentication on every request, a unified response envelope that always carries jsonrpc, id, and either result or error, and cross-network compatibility — the same request shape and SDK code targets the C-Chain (chain ID 43114) or any other network we host, with only the endpoint URL changing.
The HTTP endpoint is the right choice for single requests and straightforward integrations: reading an AVAX balance, broadcasting a signed transaction, or fetching a block on the C-Chain. Each call is an independent POST that returns one response, which keeps your code simple and stateless. For ready-to-run examples using curl, see the Quick Start guide.
The WebSocket endpoint is ideal for subscriptions and real-time data on the Avalanche C-Chain. Open a single persistent connection and stream new blocks, pending transactions, or contract event logs as they happen — perfect for keeping a trading dashboard or liquidation bot in sync with the chain's one-to-two-second finality without constant polling. See eth_subscribe for subscription examples.
Every call to the Avalanche C-Chain uses the JSON-RPC 2.0 format, a compact JSON object with four fields. jsonrpc declares the protocol version and is always the string "2.0". method names the call you want, such as eth_blockNumber. params is an array of arguments for that method, which may be empty. id is any number or string you choose to match the response back to its request, which matters when you batch or multiplex many calls over one connection.
Every response from the Avalanche C-Chain shares the same predictable structure. It echoes jsonrpc set to "2.0" and the id from your request, then carries exactly one of two outcomes: a result field on success, holding the data you asked for, or an error object on failure, holding a numeric code and a human-readable message. Because the shape never changes, your client can branch on the presence of result versus error with a single check.
Every request to the Avalanche C-Chain must carry your TheRPC API key in the Authorization header using the Bearer scheme. The key both authenticates you and ties each call to your plan's quota and rate limits. For step-by-step setup, key rotation, and security best practices, see the full Authentication guide.
The Avalanche C-Chain API is organized into namespaces by prefix. The standard set covers everyday work: eth_ for core protocol calls like reading AVAX balances and sending transactions, net_ for network status and confirming you are on chain ID 43114, and web3_ for small utility helpers. The advanced set unlocks deeper inspection on supported plans: debug_ for replaying and debugging execution, trace_ for full transaction and block tracing, and txpool_ for examining the pending transaction pool. Each prefix links through to its own method documentation on the All Methods page.
When something goes wrong, the Avalanche C-Chain API returns one of the standard JSON-RPC error codes in the error.code field. -32700 means a parse error — the request was not valid JSON. -32600 means an invalid request. -32601 means the method was not found, often a typo in the method name. -32602 means invalid params, such as a malformed address or block tag. -32603 means an internal error on the server side. For detailed handling strategies, including retries and backoff, see the FAQ.
requests to call the C-Chain.