Rate Limits

Rate limits are applied per API key using a sliding window counter. All chains share the same rate limit — your plan's limit is the total across all chains.

Plan Comparison

Rate Limit Response

When you exceed your rate limit, the API returns HTTP 429:

HTTP/1.1 429 Too Many Requests
Retry-After: 1

{
  "error": "Rate limited",
  "limit": 20,
  "plan": "Free",
  "message": "20 requests per second on the Free plan. Starter allows 70.",
  "upgrade": "https://swiftnodes.io/?plan=starter"
}

Requests over the limit are rejected immediately, not queued, and are never billed. The free plan also stops at 250,000 requests a month; paid plans have no monthly cap. Match on error; message and upgrade are absent on the top plan and custom plans.

Bursts on paid plans

Paid plans absorb short spikes. Above your per-second limit, requests up to twice the limit draw on a burst credit that holds 10 seconds of your plan's rate and refills over five minutes. A Starter key (70 req/s) can run at 140 req/s for about 10 seconds; only past twice the limit, or once the credit is spent, does it get 429. The credit refills by itself while you stay under your limit, so a full burst takes five minutes to earn back. The free plan has no burst credit: every request over 20 per second gets 429.

On the free plan, WebSocket allows one connection and new-head subscriptions only (eth_subscribe with newHeads). Log and pending-transaction subscriptions need a paid plan. On EVM chains, free new-head subscriptions come from a shared feed that polls the chain, so a new head can arrive up to about half a block time later than on a paid connection. The shared demo key is limited to 2 requests per second.

The free plan also limits the heaviest calls, over HTTP and WebSocket alike. eth_getLogs covers at most 100 blocks per request, a JSON-RPC batch holds at most 20 calls, and trace and debug methods (debug_*, trace_*) need a paid plan. Refused calls return a JSON-RPC error that says which limit applied. Paid plans have none of these limits.

Best Practices

• Implement exponential backoff when you receive 429 responses
• Cache responses where possible (e.g. eth_chainId never changes)
• Batch requests using eth_call with Multicall3 instead of making many individual calls
• Use WebSocket subscriptions instead of polling for real-time data
• Use separate API keys for different applications to track usage independently

Payments

Upgrade from your dashboard. We accept credit or debit cards, or cryptocurrency:

• ETH (Ethereum, Base, Arbitrum)
• BNB (BSC)
• USDT (Ethereum, BSC, Arbitrum)
• USDC (Ethereum, BSC, Base, Arbitrum)