Rate Limits

Rate limiting caps how many requests your API key can make in a given window. TheRPC applies it to keep the Arbitrum One service fast and fair for everyone and to protect the underlying infrastructure from bursts. Limits are enforced at several levels at once — per second, per minute, per day, and on concurrent connections — so a healthy mix of steady traffic and short spikes is fine. The exact numbers depend on your subscription plan and are always visible in your dashboard.

Error Responses

When you exceed a limit, the Arbitrum One API returns a JSON-RPC error with code -32029 and a "Rate limit exceeded" message instead of a result. Alongside it, the HTTP response carries rate-limit metadata in headers — the ceiling, how many requests remain in the window, and the Unix timestamp when the window resets — so your client can pace itself rather than guess.

Rate Limit Error — JSON-RPC

1{
2  "jsonrpc": "2.0",
3  "error": {
4    "code": -32029,
5    "message": "Rate limit exceeded"
6  },
7  "id": 1
8}

Rate Limit Response Headers

1X-RateLimit-Limit: 10
2X-RateLimit-Remaining: 0
3X-RateLimit-Reset: 1628696400

Best Practices

Three strategies keep you comfortably under the limits on Arbitrum One. Retry failed calls with exponential backoff so transient -32029 errors resolve themselves. Batch independent reads into a single JSON-RPC request to cut round trips. And replace polling with WebSocket subscriptions for any real-time data. The sections below show each in practice.

Implement Retries

1async function callWithRetry(method, params, maxRetries = 3) {
2  for (let i = 0; i < maxRetries; i++) {
3    try {
4      const response = await makeRequest(method, params);
5      return response;
6    } catch (error) {
7      if (error.code === -32029) {
8        // Rate limit exceeded
9        const backoffTime = Math.pow(2, i) * 1000;
10        await new Promise((resolve) => setTimeout(resolve, backoffTime));
11        continue;
12      }
13      throw error;
14    }
15  }
16  throw new Error('Max retries exceeded');
17}

Batch Requests

1[
2  {
3    "jsonrpc": "2.0",
4    "method": "eth_getBalance",
5    "params": ["0x742d35Cc6634C0532925a3b844Bc454e4438f44e", "latest"],
6    "id": 1
7  },
8  {
9    "jsonrpc": "2.0",
10    "method": "eth_blockNumber",
11    "params": [],
12    "id": 2
13  }
14]

Use WebSocket Subscriptions

For real-time data on Arbitrum One, eth_subscribe over WebSocket pushes new heads, logs, and pending transactions to you as they happen, eliminating the repeated polling that burns through your request quota. Given the sequencer's sub-second confirmations, a subscription is both cheaper and more responsive than a polling loop. See the eth_subscribe reference for the available subscription types and examples.

Monitoring

• Dashboard metrics — track your Arbitrum One request volume and remaining quota over time
• Response headers — read X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset on every response to pace requests
• Usage alerts — get notified before you hit a ceiling so you can react in advance

Quota Management

Read your remaining quota programmatically from the X-RateLimit-Remaining and X-RateLimit-Reset headers on each response, as the tracking helper below shows, and slow down before you hit zero. Pair this with response caching: data that changes slowly on Arbitrum One — a contract's bytecode, a finalized block, a token's metadata — can be cached locally so you do not re-request it, which meaningfully cuts your request volume.

Track Usage

1function trackApiUsage(response) {
2  const limits = {
3    limit: response.headers['X-RateLimit-Limit'],
4    remaining: response.headers['X-RateLimit-Remaining'],
5    reset: response.headers['X-RateLimit-Reset'],
6  };
7 
8  console.log(`API calls remaining: ${limits.remaining}/${limits.limit}`);
9}

Implement Caching

1const cache = new Map();
2 
3async function getCachedBlockNumber(cacheTime = 5000) {
4  const cached = cache.get('blockNumber');
5  if (cached && Date.now() - cached.timestamp < cacheTime) {
6    return cached.value;
7  }
8 
9  const newValue = await web3.eth.getBlockNumber();
10  cache.set('blockNumber', {
11    value: newValue,
12    timestamp: Date.now(),
13  });
14 
15  return newValue;
16}

Plan Limits

Plans differ along several axes: request rate, daily quota, the number of concurrent WebSocket connections, and how many subscriptions each connection may hold. Advanced plans also unlock heavier Arbitrum One capabilities — archive-state access for historical queries, the debug_ namespace, and the trace_ API for full call-tree analysis. Compare the tiers side by side on the pricing page to pick the right fit.

Upgrade Options

• Optimize requests — batch calls and trim any redundant polling against Arbitrum One
• Add caching — store slowly-changing results locally to avoid repeat requests
• Switch to WebSocket subscriptions — replace polling loops with eth_subscribe for real-time data
• Upgrade your plan — move to a higher tier for more throughput, archive data, and trace methods