Arbitrum RPC Endpoints and Providers: How Do You Pick the Right One?

Arbitrum is an EVM-compatible Layer 2, which means the RPC surface you connect to is the same JSON-RPC interface you already use on Ethereum. What changes between providers is not the method names but how the endpoint behaves under load: rate limits, archive depth, WebSocket support, and whether you share capacity with other teams.

This page is for developers and infrastructure buyers who searched for Arbitrum RPC endpoints and node providers and now need to decide what to connect to. It covers chain settings for Arbitrum One and Arbitrum Sepolia, the endpoint types available, working request examples, and the failure modes that usually force a migration.

Endpoint options: which one fits your workload

Before copying a URL, match the endpoint type to what your app actually does. Most teams start on a public endpoint and outgrow it; the question is when.

If you are validating a contract or running a one-off script, a public endpoint is fine. If you are shipping a product where a failed eth_call means a broken user experience, plan for a managed or dedicated endpoint from the start.

OnFinality provides Arbitrum RPC through a managed API and dedicated node options, so you can start on a shared endpoint and move to isolated capacity without changing your application code. See Arbitrum RPC for the current endpoint and transport details, and RPC pricing for how plans scale.

Arbitrum One and Arbitrum Sepolia chain settings

Use these values when adding Arbitrum to a wallet, a Hardhat/Foundry config, or a frontend network switcher. Keep mainnet and testnet separate — mixing them is one of the most common setup mistakes.

A public OnFinality endpoint you can use for quick checks:

# Arbitrum One
https://arbitrum.api.onfinality.io/public

# Arbitrum Sepolia
https://arbitrum-sepolia.api.onfinality.io/public

For production traffic, replace the public URL with your own authenticated endpoint from the Arbitrum network page. Public URLs are shared and are not intended for sustained load.

Adding Arbitrum to a wallet or app config

If you are wiring Arbitrum into a frontend, the network configuration usually looks like this:

const arbitrumOne = {
  chainId: '0x' + (42161).toString(16), // 0xa4b1
  chainName: 'Arbitrum One',
  nativeCurrency: { name: 'Ether', symbol: 'ETH', decimals: 18 },
  rpcUrls: ['https://arbitrum.api.onfinality.io/public'],
  blockExplorerUrls: ['https://arbiscan.io'],
};

await window.ethereum.request({
  method: 'wallet_addEthereumChain',
  params: [arbitrumOne],
});

For a viem or ethers client, point the transport at the same URL and let the library handle retries:

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(block);

What a basic Arbitrum request looks like

Every Arbitrum endpoint speaks JSON-RPC over HTTP POST. A minimal health check is eth_chainId, which should return 0xa4b1 on Arbitrum One.

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

A more realistic call fetches the latest block and a contract read:

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

If eth_chainId works but your application calls fail, the problem is usually the method, the parameters, or a rate limit — not the endpoint URL itself.

Methods that decide your provider choice

Most Arbitrum apps only need a handful of methods, but a few of them separate a basic endpoint from one that can carry production traffic.

If your workload depends on eth_getLogs over wide block ranges, debug_* methods, or WebSocket subscriptions, confirm those are supported before committing to a provider. OnFinality's Arbitrum support includes HTTP and WebSocket transport — check the Arbitrum network page for the current method and transport coverage.

Common failure modes and how to read them

When an Arbitrum integration breaks, the error usually points at one of four causes. Match the symptom to the fix before assuming the provider is down.

A quick diagnostic loop: call eth_chainId to confirm connectivity, then eth_blockNumber to confirm the node is synced, then retry the failing method with a smaller payload. If the first two succeed and only the third fails, the issue is method support or request size, not the endpoint.

Production readiness checklist

Before you route real traffic to an Arbitrum endpoint, confirm these points. They are the same questions that come up in a provider evaluation.

• Transport: Do you need HTTP only, or WebSocket for subscriptions?
• Archive depth: Does your app query historical state, or only recent blocks?
• Trace methods: Do you rely on debug_* or trace_* calls?
• Rate limits: What happens during a burst — throttling, queueing, or hard errors?
• Failover: Can you switch endpoints without redeploying?
• Observability: Can you measure error rate and latency per endpoint?
• Testnet parity: Does your provider cover Arbitrum Sepolia so staging matches production?

If you answer "yes" to archive, trace, or WebSocket needs, a shared public endpoint will not hold. A managed RPC API or a dedicated node is the more realistic path. For a broader framework, see how to choose an RPC provider.

Migrating between Arbitrum endpoints

Because Arbitrum is EVM-compatible, migrating endpoints is mostly a configuration change, not a code rewrite. The safe sequence:

1. Add the new endpoint alongside the old one in your config.
2. Run both in parallel and compare responses for the same block height.
3. Shift read traffic first, then writes and subscriptions.
4. Keep the old endpoint as a fallback until the new one has run through a full traffic cycle.
5. Remove the old endpoint only after your monitoring shows stable error rates.

If you use a client library, keep the endpoint in an environment variable so switching does not require a code change or redeploy.

Key Takeaways

• Arbitrum uses standard EVM JSON-RPC, so tooling compatibility is rarely the blocker — endpoint capacity and method support are.
• Arbitrum One uses chain ID 42161; Arbitrum Sepolia uses 421614. Keep them separate in configs.
• Public endpoints are fine for tests but are shared and rate-limited; production apps need an authenticated or dedicated endpoint.
• eth_getLogs, debug_*, and eth_subscribe are the methods that most often force a provider upgrade.
• OnFinality offers Arbitrum RPC through a managed API and dedicated nodes, with HTTP and WebSocket transport. See Arbitrum RPC, RPC pricing, and supported RPC networks.

Frequently Asked Questions

What is the Arbitrum One RPC endpoint?

Arbitrum One is reachable at any EVM-compatible JSON-RPC endpoint. OnFinality provides a public endpoint at https://arbitrum.api.onfinality.io/public for testing, and authenticated endpoints for production. See the Arbitrum network page for current details.

What chain ID does Arbitrum use?

Arbitrum One uses chain ID 42161. Arbitrum Sepolia, the testnet, uses 421614. Always confirm the chain ID your wallet or client reports before sending transactions.

Do I need a dedicated Arbitrum node?

Not always. If your app makes steady, low-volume reads, a managed shared endpoint may be enough. If you run indexers, trading bots, or archive queries, or you need predictable capacity and WebSocket subscriptions, a dedicated node is usually the better fit.

Does Arbitrum support WebSocket RPC?

Arbitrum One supports WebSocket transport, which is required for eth_subscribe event streams. Confirm WebSocket availability with your provider, since not every endpoint exposes it.

Why does my Arbitrum request return a rate-limit error?

Public and shared endpoints apply rate limits to protect capacity. If you see 429 responses during normal traffic, move to an authenticated endpoint or a dedicated node with capacity sized to your workload.

How do I test an Arbitrum endpoint before switching?

Call eth_chainId to confirm connectivity, eth_blockNumber to confirm the node is synced, then replay a few real requests from your app. Run the new endpoint in parallel with the old one before cutting over.