Zum Hauptinhalt springen

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:
TarifRPC Rate LimitDAS und erweiterte APIs
Free10 requests/s2 requests/s
Developer50 requests/s10 requests/s
Business200 requests/s50 requests/s
Professional500 requests/s100 requests/s
EnterpriseBenutzerdefiniertBenutzerdefiniert

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

EndpointFreeDeveloperBusinessProfessional
Sender50/s50/s50/s50/s
sendTransaction1/s5/s50/s100/s
sendBundle——5/s5/s
simulateBundle10/s50/s200/s500/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.
Wenn du einen Professional-Tarif nutzt und das rate limit für 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

EndpointFreeDeveloperBusinessProfessional
getProgramAccounts5/Sek.25/Sek.50/Sek.75/Sek.

Historische Daten

Für Batch-request an Methoden für historische Daten gelten die folgenden Limits:
MethodeMaximale Batchgröße
getTransaction100 Elemente pro request
getTransactionsForAddressKeine Batch-request erlaubt
getTransfersByAddressKeine Batch-request erlaubt
Alle anderen Methoden für historische Daten10 Elemente pro request
Wenn du die Batch-Limits überschreitest, erhältst du eine Fehler-response. Bei getTransactionsForAddress und getTransfersByAddress musst du jede Adresse in einem separaten request abfragen.

LaserStream

RessourceFreeDeveloperBusinessProfessional
Netzwerke—DevnetDevnet, MainnetDevnet, Mainnet
Maximale Anzahl an Pubkeys—10M10M10M
Aktive Verbindungen——10100

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:
EndpointFreeDeveloperBusinessProfessional
Alle Endpoint der Wallet API2/Sek.10/Sek.50/Sek.100/Sek.
Dazu gehören Endpoint für Identitätsabfragen, Guthaben, Verlauf, Übertragungen und Finanzierungsquellen. Weitere Informationen findest du in unserer Dokumentation zur Wallet API.

Geparste Streams

RessourceFreeDeveloperBusinessProfessional
Gleichzeitige Verbindungen5105050
Abonnements pro Verbindung25252525
Verbindungen werden pro Projekt über alle zugehörigen API key hinweg gezählt. Ein Projekt, das sein Verbindungslimit erreicht hat, erhält HTTP 429. Unter Limits für Parsed Streams findest du die Limits pro Filter und für Nachrichten.

LaserStream WebSocket

RessourceFreeDeveloperBusinessProfessional
Gleichzeitige Verbindungen51502501.000
Abonnements pro Verbindung1.0001.0001.0001.000
WebSocket-TypenStandardStandard, erweitertStandard, erweitertStandard, erweitert

Webhooks

RessourceFreeDeveloperBusinessProfessional
Maximale Anzahl an webhook5505050
Adressen pro webhook100k100k100k100k

ZK-Komprimierung

DienstFreeDeveloperBusinessProfessional
Photon APIs2/Sek.10/Sek.50/Sek.100/Sek.
getValidityProof1/Sek.5/Sek.10/Sek.20/Sek.

Wiederholungsversuche und Fehlerbehandlung

Wenn deine Anwendung eine 429 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.

Bei welchen Fehlern du es erneut versuchen solltest

Beispiel

Format der Fehler-response

Alle Helius APIs geben bei Fehlern einen strukturierten JSON-Inhalt zurück. JSON-RPC-endpoint (Solana RPC, DAS, Sender, Priority Fee, ZK-Komprimierung) geben das standardmäßige JSON-RPC-2.0-Format zurück:
REST-endpoint (Wallet API, Admin API) geben Folgendes zurück:
Unter Häufige Fehlercodes findest du die vollständige Liste der Fehlercodes und ihre jeweilige Bedeutung.