Arbitrum API Overview: RPC Endpoints, Chain Settings, and Production Setup

Which Arbitrum endpoint should you connect to first?

If you are building on Arbitrum, the first decision is not which method to call — it is which endpoint to call it against. Arbitrum has two networks you will touch: Arbitrum One (mainnet, chain ID 42161) and Arbitrum Sepolia (testnet, chain ID 421614). Both expose an Ethereum-compatible JSON-RPC API, so the same client libraries, wallet configs, and contract tooling work on either one.

Use this quick routing table before you write any code:

OnFinality exposes Arbitrum endpoints through its RPC API service and dedicated node options. You can review the network details on the Arbitrum network page.

Arbitrum chain settings at a glance

Wallets and frameworks such as Hardhat, Foundry, ethers, and viem need the same handful of parameters. Keep them consistent across environments so you do not accidentally point a staging build at mainnet.

A wallet network configuration looks like this:

await window.ethereum.request({
  method: "wallet_addEthereumChain",
  params: [{
    chainId: "0xa4b1", // 42161 in hex
    chainName: "Arbitrum One",
    nativeCurrency: { name: "Ether", symbol: "ETH", decimals: 18 },
    rpcUrls: ["https://arbitrum.api.onfinality.io/public"],
    blockExplorerUrls: ["https://arbiscan.io"]
  }]
});

For Sepolia, swap chainId to 0xa4ba (421614), the chain name, the RPC URL, and the explorer URL. Public endpoints are convenient for development, but production traffic should go through a managed or dedicated endpoint so you control throughput and availability.

Making your first JSON-RPC request

Arbitrum speaks standard Ethereum JSON-RPC. A minimal health check is eth_blockNumber, which confirms the endpoint is reachable and synced enough to answer:

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

A response returns the latest block height in hex. From there, the methods you will use most are eth_getBalance, eth_getTransactionCount, eth_call, eth_estimateGas, eth_getLogs, and eth_sendRawTransaction. Because Arbitrum is EVM-equivalent, contract ABIs and Solidity tooling carry over from Ethereum with few changes.

In JavaScript, using viem against an Arbitrum endpoint looks like this:

import { createPublicClient, http } from "viem";
import { arbitrum } from "viem/chains";

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

const block = await client.getBlockNumber();
console.log("Latest Arbitrum block:", block);

If you need push-based updates rather than polling, connect over WebSocket to a provider that supports it and subscribe to newHeads or logs. Arbitrum One supports WebSocket transport on OnFinality; Sepolia is HTTP-only in the current network configuration.

Method support and Arbitrum-specific behavior

Most Ethereum JSON-RPC methods work as expected, but a few areas deserve attention when you move from a testnet to production:

• Logs and filters. eth_getLogs is the backbone of indexers and event-driven backends. Wide block ranges and unfiltered queries are the most common cause of timeouts. Narrow your range and filter by address and topic.
• Gas estimation. Arbitrum has its own fee model layered on top of Ethereum's. eth_estimateGas still works, but do not hard-code gas prices copied from Ethereum mainnet.
• Archive data. Historical state queries, such as balances at an old block, require an archive-capable node. Confirm archive access with your provider before you build analytics or accounting features.
• Trace and debug methods. Debug and trace APIs are useful for transaction simulation and incident analysis, but support varies by provider and node type. Ask explicitly rather than assuming.
• Batch requests. JSON-RPC batching reduces round trips for dashboards and wallets. Check whether your endpoint plan supports it.

A practical rule: list every non-standard method your app calls, then confirm each one against your provider's documentation before launch. Standard methods are usually safe; debug, trace, and archive queries are where surprises appear.

Public, shared, or dedicated: choosing Arbitrum node infrastructure

Once your prototype works, the next decision is operational. There are three broad ways to get an Arbitrum endpoint, and they trade control against effort.

OnFinality offers managed RPC through its API service and dedicated Arbitrum nodes through dedicated node infrastructure. Pricing scales with the option you choose; see RPC pricing for current plans. For a broader framework on evaluating providers, the RPC provider selection guide covers workload sizing, failover, and support expectations.

Production readiness checklist for Arbitrum APIs

Before you route real users through an Arbitrum endpoint, walk through these checkpoints. They catch the majority of issues that surface after launch.

1. Separate keys per environment. Use distinct API keys or endpoints for staging and production so a runaway test script cannot exhaust production throughput.
2. Add a fallback endpoint. Configure a secondary RPC URL in your client so a single provider incident does not take down your app.
3. Set request timeouts and retries. JSON-RPC calls can be slow under load; wrap them with timeouts and bounded retries with backoff.
4. Monitor block lag. Poll eth_blockNumber on a schedule and alert if your endpoint falls behind the network.
5. Cap eth_getLogs ranges. Chunk large historical scans into bounded windows and persist progress.
6. Confirm archive and trace needs. If you query old state or simulate transactions, verify those methods are enabled on your plan.
7. Test WebSocket reconnects. If you subscribe to events, handle disconnects and re-subscribe cleanly.

A simple monitoring probe you can run on a schedule:

#!/usr/bin/env bash
RPC="https://arbitrum.api.onfinality.io/public"
HEIGHT=$(curl -s "$RPC" -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' \
  | sed -E 's/.*"result":"(0x[0-9a-f]+)".*/\1/')
echo "Arbitrum block height: $((HEIGHT))"

Log the result and alert on unexpected gaps. This is a lightweight signal, not a full observability stack, but it catches the most common failure mode: an endpoint that is reachable but stale.

Common failure modes and how to debug them

When an Arbitrum API call fails, the error message often points at the symptom rather than the cause. Use this map to move from symptom to next step.

Start with the simplest check: does eth_blockNumber respond? If yes, the endpoint is up and the problem is likely method-specific, parameter-specific, or quota-related. If no, treat it as a connectivity or provider incident and fail over.

Migrating from another Arbitrum provider

Switching Arbitrum RPC providers is usually a configuration change, not a rewrite, because the API is Ethereum-compatible. A safe migration follows four steps:

1. Inventory your methods. List every JSON-RPC method your app calls, including debug, trace, and archive queries.
2. Run both endpoints in parallel. Point a staging environment at the new endpoint and compare responses for the same blocks and calls.
3. Verify transport needs. Confirm HTTP and WebSocket support match what your client expects.
4. Cut over with a fallback. Keep the old endpoint as a secondary URL until the new one has run cleanly through a full release cycle.

Because chain IDs and chain names are identical across providers, you do not need to change wallet configs or contract addresses. The main risks are method support gaps and throughput limits, both of which the parallel-run step surfaces early.

Key Takeaways

• Arbitrum exposes an Ethereum-compatible JSON-RPC API on Arbitrum One (chain ID 42161) and Arbitrum Sepolia (chain ID 421614).
• Standard methods like eth_call, eth_getLogs, and eth_sendRawTransaction work as expected; debug, trace, and archive methods need explicit confirmation.
• Public endpoints are fine for prototyping but not for production traffic; shared managed RPC and dedicated nodes cover production workloads.
• OnFinality provides Arbitrum RPC through its API service and dedicated nodes; see RPC pricing and supported RPC networks for details.
• A production checklist — separate keys, fallback endpoints, block-lag monitoring, and bounded log queries — prevents most post-launch incidents.

Frequently Asked Questions

What is the Arbitrum chain ID? Arbitrum One uses chain ID 42161; Arbitrum Sepolia uses 421614. Both use ETH as the native currency.

Is the Arbitrum API the same as Ethereum's? It is Ethereum-compatible JSON-RPC, so most methods, client libraries, and tooling work unchanged. Some fee-model and method-support details differ, so verify non-standard methods with your provider.

Can I use a public Arbitrum RPC endpoint in production? Public endpoints are best for development and testing. For production, use a managed or dedicated endpoint so you control throughput, availability, and method support.

Does Arbitrum support WebSocket subscriptions? Arbitrum One supports WebSocket transport on OnFinality; Arbitrum Sepolia is HTTP-only in the current network configuration. Confirm with your provider before relying on subscriptions.

How do I get testnet ETH for Arbitrum Sepolia? Use a Sepolia faucet to obtain test ETH, then bridge or use it directly on Arbitrum Sepolia. Faucet availability changes, so check current sources before relying on one.

Where can I find OnFinality's Arbitrum endpoint details? See the Arbitrum network page for endpoint and chain settings, and RPC pricing for plan options.