Ethereum
FAQ
Authentication & Access
- How do I get an API key? Sign up at TheRPC.io, open the Dashboard, go to API Keys, and generate one. It authenticates against the Ethereum endpoint right away.
- Can I have more than one key? Yes, and it is worth it. A key per app and per environment means you can revoke a leaked staging key without disrupting production chain 1 traffic, and the Dashboard shows CU usage broken out per key so you can see which workload is spending.
- What if a key leaks? Revoke it from the Dashboard immediately — a revoked key stops authenticating on the spot — then generate a replacement and swap it into your environment. A leaked key on a public repo can be drained of CUs within minutes, so do not wait.
API Usage
- HTTP or WebSocket? Use the HTTP endpoint for one-off reads and broadcasts —
eth_getBalance,eth_call,eth_sendRawTransaction. Use the WebSocket endpoint when you need the node to push data to you: new blocks each 12-second slot, livelogs, or pending transactions viaeth_subscribe, which only works over WebSocket. - How do I handle rate limits? Back off exponentially when you see the rate-limit error code and retry, rather than hammering the endpoint. If you hit limits steadily rather than in bursts, that is a signal to upgrade your plan.
- What timeouts should I set? Around 30 seconds for HTTP requests, a 60-second WebSocket ping/pong interval to keep the connection alive, and roughly 30 seconds for subscription setup operations.
Error Handling
The Ethereum endpoint returns the standard JSON-RPC error codes, summarized in the table below: -32700 for unparseable JSON, -32600 for a malformed request object, -32601 for an unknown method name, which is usually a misspelling or a namespace your tier has not unlocked, -32602 for bad params like a malformed address or block tag, -32603 for an internal node error, and the -32000 to -32099 range for server-side conditions. Four habits keep error handling sane: always check whether the error field is present before reading result; retry transient failures and rate limits with exponential backoff rather than tight loops; log the code and message so you can tell a bad address from a node hiccup; and set request timeouts so a slow call fails cleanly instead of hanging.
Common Error Response
Standard JSON-RPC Error Codes
| Code | Meaning |
|---|---|
-32700 | Parse error |
-32600 | Invalid request |
-32601 | Method not found |
-32602 | Invalid params |
-32603 | Internal error |
-32000 to -32099 | Server error |
Technical Questions
- How do I track a pending transaction? Poll
eth_getTransactionReceiptby hash — a null result means it is still pending, a receipt means it landed. For a push-based approach, subscribe tonewHeadsover WebSocket and check for your hash as each block arrives. - How do I keep my own transactions in order? Sequence them by nonce. Fetch the current nonce with
eth_getTransactionCount, then assign each outgoing transaction the next integer and submit them through an application-level queue so a gap never leaves later ones stuck in the queued pool. - How do I deal with reorgs? At the chain head, short single-block reorgs are possible before a block is justified, so do not treat a fresh
latestblock as settled. For anything involving money, read at thefinalizedtag viaeth_getBlockByNumber— once Casper FFG finalizes a checkpoint (about 12.8 minutes, two epochs), it cannot be reverted without a third of all staked ETH being slashed. Wait for confirmations by watchingeth_blockNumberclimb, or usesafewhen you want a softer guarantee thanfinalizedbut firmer thanlatest.
Transaction Tracking Example
Performance
- How do I cut down on calls? Batch independent reads into a single JSON-RPC array so several balances or block lookups go over one HTTP round trip. Switch to WebSocket subscriptions for anything real-time so you stop polling. Cache values that change slowly — chain ID, contract bytecode, old finalized blocks — and tune polling intervals to the 12-second slot rather than spinning faster than blocks are produced.
- What about high throughput? Pool and reuse connections instead of opening one per request, queue outgoing requests so you stay under your rate limit, watch the rate-limit response headers to see headroom in real time, and move heavy or latency-sensitive workloads onto a higher plan with dedicated capacity.
Network Specific
- How do I switch networks? Change the endpoint URL and nothing else. The same API key authenticates everywhere, and the JSON-RPC request format is identical, so moving from Ethereum mainnet to Sepolia or back is a one-line swap. Confirm where you landed by calling
net_version, which returns1for mainnet. - How do I verify I'm on Ethereum mainnet? Call
eth_chainId; it returns0x1, the hex for chain ID 1. Because the code is portable across networks, this check is the cheapest guard against accidentally sending a real transaction against a testnet or vice versa.
Development & Integration
- Which library should I use? In JavaScript or TypeScript, ethers.js or web3.js. In Python, web3.py. In Java or Kotlin, web3j. Each speaks plain JSON-RPC under the hood, so they all point at the Ethereum endpoint the same way — see Tools & SDKs for the full list including Go, Rust, PHP, and more.
- How do I test an integration before going live? Start against a testnet like Sepolia with a separate test key, wire up error handling for the JSON-RPC codes early, and sanity-check connectivity with a cheap
eth_blockNumbercall before anything heavier. Watch latency and CU usage in the Dashboard as you ramp up, then point the same code at chain 1 by swapping the endpoint.