RPC error HTTP 429: Too Many Requests
Last updated:
At a glance
| Property | Value |
|---|---|
| Code | HTTP 429 |
| Message | Too Many Requests |
| Category | transport |
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
- 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.
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.