What are rate limits?
Rate limits control how many requests you can make per second. When rate limits are exceeded, you’ll receive an HTTP 429 response. For guidance on what to do when you hit a 429 or other transient failure, see Retries and error handling below.Standard Rate Limits
Your plan has two standard rate limit groups: one for RPC requests, and one for DAS API requests. Here are the base rate limits for each Helius plan:| Plan | RPC Rate Limit | DAS & Enhanced APIs |
|---|---|---|
| Free | 10 requests/s | 2 requests/s |
| Developer | 50 requests/s | 10 requests/s |
| Business | 200 requests/s | 50 requests/s |
| Professional | 500 requests/s | 100 requests/s |
| Enterprise | Custom | Custom |
Increase Rate Limits
Teams on Professional plans can purchase an extra 100 RPS for $100 USD/month. If you need custom rate limits ahead of launches, contact our sales team. If you are on Developer or Business tier, please upgrade your plan to increase your rate limits.Special Rate Limits
Some endpoints and specialized Helius products have special rate limits due to their computational requirements.Sending Transactions
| Endpoint | Free | Developer | Business | Professional |
|---|---|---|---|---|
Sender | 50/sec | 50/sec | 50/sec | 50/sec |
sendTransaction | 1/sec | 5/sec | 50/sec | 100/sec |
sendBundle | — | — | 5/sec | 5/sec |
simulateBundle | 10/sec | 50/sec | 200/sec | 500/sec |
Sender keyless
/fast requests are limited to 1 request per second per egress
IP, per region. Callers behind the same NAT share this limit. Rejected 429
requests count toward the limit; /ping does not. Append your existing Helius
project API key for the 50 requests per second, per-key, per-region limit.sendTransaction rate limits, contact our sales team.
Professional plan users can also request rate limit increases and custom tip arrangements for Sender to support higher-throughput trading apps.
Complex RPC Calls
| Endpoint | Free | Developer | Business | Professional |
|---|---|---|---|---|
getProgramAccounts | 5/sec | 25/sec | 50/sec | 75/sec |
Historical Data
When making batch requests for historical data methods, the following limits apply:| Method | Max Batch Size |
|---|---|
getTransaction | 100 items per request |
getTransactionsForAddress | No batch requests allowed |
getTransfersByAddress | No batch requests allowed |
| All other historical methods | 10 items per request |
LaserStream
| Resource | Free | Developer | Business | Professional |
|---|---|---|---|---|
| Networks | — | Devnet | Devnet, Mainnet | Devnet, Mainnet |
| Max Pubkeys | — | 10M | 10M | 10M |
| Active Connections | — | — | 10 | 100 |
Wallet API
The Wallet API follows the same rate limits as DAS & Enhanced APIs. All endpoints share these limits:| Endpoint | Free | Developer | Business | Professional |
|---|---|---|---|---|
| All Wallet API Endpoints | 2/sec | 10/sec | 50/sec | 100/sec |
Parsed Streams
| Resource | Free | Developer | Business | Professional |
|---|---|---|---|---|
| Concurrent Connections | 5 | 10 | 50 | 50 |
| Subscriptions per Connection | 25 | 25 | 25 | 25 |
LaserStream WebSocket
| Resource | Free | Developer | Business | Professional |
|---|---|---|---|---|
| Concurrent Connections | 5 | 150 | 250 | 1,000 |
| Subscriptions per Connection | 1,000 | 1,000 | 1,000 | 1,000 |
| WebSocket Types | Standard | Standard, Enhanced | Standard, Enhanced | Standard, Enhanced |
Webhooks
| Resource | Free | Developer | Business | Professional |
|---|---|---|---|---|
| Max Webhooks | 5 | 50 | 50 | 50 |
| Addresses per Webhook | 100k | 100k | 100k | 100k |
ZK Compression
| Service | Free | Developer | Business | Professional |
|---|---|---|---|---|
| Photon APIs | 2/sec | 10/sec | 50/sec | 100/sec |
getValidityProof | 1/sec | 5/sec | 10/sec | 20/sec |
Retries and error handling
When your application receives a429 Too Many Requests, 503 Service Unavailable, or transient 5xx response, wait a moment and retry — don’t retry immediately. Immediate retries pile up requests and make rate-limit recovery slower, not faster.
Recommended strategy
- Wait about 1 second before the first retry.
- Double the wait each time you retry, up to a maximum of 30 seconds.
- Add a small random variation of ±25% to each wait so multiple applications don’t all retry at the same instant.
- Give up after 5 attempts and return the error to the code that called you.