Was sind rate limits?
Rate limits steuern, wie viele requests du pro Sekunde senden kannst. Wenn du die rate limits überschreitest, erhältst du eine HTTP-429-response. Was du bei einem 429-Fehler oder einem anderen vorübergehenden Fehler tun solltest, erfährst du unten unter Wiederholungsversuche und Fehlerbehandlung.Standardmäßige Rate Limits
Dein Tarif umfasst zwei Standardgruppen für rate limits: eine für RPC-requests und eine für DAS API-requests. Dies sind die grundlegenden rate limits für jeden Helius-Tarif:| Tarif | RPC Rate Limit | DAS und erweiterte 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 | Benutzerdefiniert | Benutzerdefiniert |
Rate Limits erhöhen
Teams mit einem Professional-Tarif können zusätzliche 100 RPS für 100 USD pro Monat erwerben. Wenn du vor einem Launch benutzerdefinierte rate limits benötigst, kontaktiere unser Vertriebsteam. Wenn du den Developer- oder Business-Tarif nutzt, führe ein Upgrade durch, um deine rate limits zu erhöhen.Besondere Rate Limits
Einige endpoints und spezialisierte Helius-Produkte haben aufgrund ihrer Rechenanforderungen besondere rate limits.Transaktionen senden
| Endpoint | Free | Developer | Business | Professional |
|---|---|---|---|---|
Sender | 50/s | 50/s | 50/s | 50/s |
sendTransaction | 1/s | 5/s | 50/s | 100/s |
sendBundle | — | — | 5/s | 5/s |
simulateBundle | 10/s | 50/s | 200/s | 500/s |
Für keyless
/fast-request von Sender gilt pro ausgehender
IP und Region ein Limit von 1 request pro Sekunde. Aufrufer hinter demselben NAT teilen sich dieses Limit. Abgelehnte 429-request
zählen zum Limit; /ping nicht. Hänge deinen vorhandenen Helius
project API key an, um das Limit von 50 request pro Sekunde, API key und Region zu erhalten.sendTransaction erhöhen musst, kontaktiere unser Vertriebsteam.
Nutzer des Professional-Tarifs können außerdem eine Erhöhung des rate limit anfragen und individuelle Tip-Vereinbarungen für Sender treffen, um Trading-Apps mit höherem Durchsatz zu unterstützen.
Komplexe RPC-Aufrufe
| Endpoint | Free | Developer | Business | Professional |
|---|---|---|---|---|
getProgramAccounts | 5/Sek. | 25/Sek. | 50/Sek. | 75/Sek. |
Historische Daten
Für Batch-request an Methoden für historische Daten gelten die folgenden Limits:| Methode | Maximale Batchgröße |
|---|---|
getTransaction | 100 Elemente pro request |
getTransactionsForAddress | Keine Batch-request erlaubt |
getTransfersByAddress | Keine Batch-request erlaubt |
| Alle anderen Methoden für historische Daten | 10 Elemente pro request |
LaserStream
| Ressource | Free | Developer | Business | Professional |
|---|---|---|---|---|
| Netzwerke | — | Devnet | Devnet, Mainnet | Devnet, Mainnet |
| Maximale Anzahl an Pubkeys | — | 10M | 10M | 10M |
| Aktive Verbindungen | — | — | 10 | 100 |
Wallet API
Für die Wallet API gelten dieselben rate limits wie für DAS und die erweiterten APIs. Diese Limits gelten gemeinsam für alle endpoint:| Endpoint | Free | Developer | Business | Professional |
|---|---|---|---|---|
| Alle Endpoint der Wallet API | 2/Sek. | 10/Sek. | 50/Sek. | 100/Sek. |
Geparste Streams
| Ressource | Free | Developer | Business | Professional |
|---|---|---|---|---|
| Gleichzeitige Verbindungen | 5 | 10 | 50 | 50 |
| Abonnements pro Verbindung | 25 | 25 | 25 | 25 |
LaserStream WebSocket
| Ressource | Free | Developer | Business | Professional |
|---|---|---|---|---|
| Gleichzeitige Verbindungen | 5 | 150 | 250 | 1.000 |
| Abonnements pro Verbindung | 1.000 | 1.000 | 1.000 | 1.000 |
| WebSocket-Typen | Standard | Standard, erweitert | Standard, erweitert | Standard, erweitert |
Webhooks
| Ressource | Free | Developer | Business | Professional |
|---|---|---|---|---|
| Maximale Anzahl an webhook | 5 | 50 | 50 | 50 |
| Adressen pro webhook | 100k | 100k | 100k | 100k |
ZK-Komprimierung
| Dienst | Free | Developer | Business | Professional |
|---|---|---|---|---|
| Photon APIs | 2/Sek. | 10/Sek. | 50/Sek. | 100/Sek. |
getValidityProof | 1/Sek. | 5/Sek. | 10/Sek. | 20/Sek. |
Wiederholungsversuche und Fehlerbehandlung
Wenn deine Anwendung eine429 Too Many Requests-, 503 Service Unavailable- oder vorübergehende 5xx-response erhält, warte einen Moment und versuche es erneut. Wiederhole den request nicht sofort. Sofortige Wiederholungen häufen request an und verlangsamen die Erholung vom rate limit, statt sie zu beschleunigen.
Empfohlene Strategie
- Warte vor dem ersten Wiederholungsversuch etwa 1 Sekunde.
- Verdopple die Wartezeit bei jedem weiteren Versuch bis auf maximal 30 Sekunden.
- Variiere jede Wartezeit zufällig um ±25 %, damit mehrere Anwendungen den request nicht gleichzeitig wiederholen.
- Brich nach 5 Versuchen ab und gib den Fehler an den aufrufenden Code zurück.