RPC error HTTP 429: Too Many Requests

Last updated:

At a glance

Error details
PropertyValue
CodeHTTP 429
MessageToo Many Requests
Categorytransport

Cause

Your key went over the requests-per-second budget its plan allows for this method category. Triport meters throughput, not a monthly request count: every method belongs to a category (sol_read_rpc, sol_read_rpc_heavy, sol_send_tx and so on), each category has its own RPS budget per tier, and a short burst on top of it. The request is rejected before it reaches a node. You do not have to guess which budget you hit — the response says so: limit_rps, burst_capacity, category and current_tier. A JSON-RPC batch is charged one token per sub-request, not one per HTTP call, so a 50-call batch spends 50 of your budget. Batching saves round-trips, not rate limit.

Solution

  1. Read the budget you actually hit from the response body: limit_rps and burst_capacity for category on your current_tier.
  2. Wait out Retry-After (seconds, never below 1) before retrying at all; X-RateLimit-Reset carries the same moment as a Unix timestamp.
  3. Only then retry, backing off exponentially with jitter — clients that all obey the same Retry-After in lockstep rebuild the very spike that caused the limit.
  4. Cap client concurrency. Overshoot usually comes from the number of parallel workers, not from a deliberately high request rate.
  5. Cache hot reads and share results between workers. Batching is not a substitute here — see the per-sub-request cost above.
  6. Replace polling with a WebSocket subscription where one exists. The same budget applies there: on WS the socket is closed with code 4029. Spreading the same traffic across extra API keys is not a way around the limit — it is the limit being circumvented. If your peak genuinely needs more throughput, move to the plan whose RPS budget covers it.

Example

{
  "body": {
    "error": "rate_limited",
    "message": "Rate limit exceeded: 60 RPS sustained on sol_read_rpc (basic tier)",
    "category": "sol_read_rpc",
    "limit_rps": 60,
    "current_tier": "basic",
    "burst_capacity": 120,
    "retry_after_sec": 1
  },
  "status": 429,
  "headers": {
    "Retry-After": "1",
    "X-RateLimit-Reset": "1758013200"
  }
}

FAQ

Why does "Too Many Requests" happen?
Your key went over the requests-per-second budget its plan allows for this method category. Triport meters throughput, not a monthly request count: every method belongs to a category (sol_read_rpc, sol_read_rpc_heavy, sol_send_tx and so on), each category has its own RPS budget per tier, and a short burst on top of it. The request is rejected before it reaches a node. You do not have to guess which budget you hit — the response says so: limit_rps, burst_capacity, category and current_tier. A JSON-RPC batch is charged one token per sub-request, not one per HTTP call, so a 50-call batch spends 50 of your budget. Batching saves round-trips, not rate limit.
How do I fix "Too Many Requests"?
Read the budget you actually hit from the response body: limit_rps and burst_capacity for category on your current_tier. Wait out Retry-After (seconds, never below 1) before retrying at all; X-RateLimit-Reset carries the same moment as a Unix timestamp. Only then retry, backing off exponentially with jitter — clients that all obey the same Retry-After in lockstep rebuild the very spike that caused the limit. Cap client concurrency. Overshoot usually comes from the number of parallel workers, not from a deliberately high request rate. Cache hot reads and share results between workers. Batching is not a substitute here — see the per-sub-request cost above. Replace polling with a WebSocket subscription where one exists. The same budget applies there: on WS the socket is closed with code 4029. Spreading the same traffic across extra API keys is not a way around the limit — it is the limit being circumvented. If your peak genuinely needs more throughput, move to the plan whose RPS budget covers it.