# Webhooks, WebSocket oder RPC-Polling wählen > Source: https://docs.blockvectra.com/de/guides/webhook-vs-websocket/ Verwenden Sie Adress-Webhooks für die Zustellung an einen HTTPS-Empfänger, WebSocket für unterstützte Live-Abonnements und begrenztes Polling, wenn der Workflow einen eigenen Cursor und eine eigene Wiederherstellung benötigt. Das Erstellen von On-Chain-Event-Listenern für Entwickler und KI-Agenten erfordert die Abstimmung der Anwendungsarchitektur auf Netzwerkfähigkeiten, Zustellgarantien, Empfängereinschränkungen und Betriebskosten. ## Entscheidungsmatrix Die folgende Tabelle stellt alle drei Integrationsmechanismen hinsichtlich unterstützter Netzwerkfähigkeiten, Infrastrukturanforderungen, Wiederherstellungsstrategien und Abrechnungsmodelle gegenüber: | Dimension | Adress-Webhooks | WebSocket-Abonnements | Begrenztes RPC-Polling | | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Primärer Mechanismus** | Per HTTPS-POST an einen öffentlichen Endpunkt zugestellte Push-Benachrichtigung | Pull-Stream-Abonnement über eine dauerhafte TLS-Verbindung (`wss://`) | Client-initiierte HTTP-JSON-RPC-Batch- oder geplante Abfragen | | **Chain-Verfügbarkeit** | Alle unterstützten Netzwerke, die in [GET /v1/push/chains](https://api.blockvectra.com/v1/push/chains) deklariert sind | Unterstützt auf Robinhood Chain (robinhood\_mainnet und robinhood\_testnet); nicht bediente Netzwerke haben `ws: false` und geben HTTP 404 zurück | Alle unterstützten Netzwerke in [GET /v1/chains](https://api.blockvectra.com/v1/chains) über schlüssellosen öffentlichen RPC oder authentifizierten JSON-RPC | | **Empfängeranforderungen** | Öffentlich erreichbare HTTPS-URL, gültiges TLS-Zertifikat, 2xx-Antwort innerhalb des Timeouts, HMAC-SHA-256-Signaturverifizierung über den Raw-Body | Ausgehende TCP/TLS-Client-Verbindung (`wss://`); verarbeitet Ping/Pong-Heartbeats und Wiederverbindungs-Backoff | Zustandsloser HTTP-Client oder geplanter Worker; speichert lokalen Block-Cursor | | **Zustellung & Reihenfolge** | Mindestens-einmal-Zustellung mit exponentiellem Wiederholungs-Backoff; Empfänger muss nach Ereignis-`id` bzw. über Abonnements hinweg nach `ref` + `type` deduplizieren | Streng geordnete Frames auf einem einzelnen aktiven Socket; Benachrichtigungen werden bei Verbindungsabbrüchen verworfen | Deterministische Pull-Antworten für bestätigte Blockhöhen; Client steuert die Ausführungsgeschwindigkeit | | **Chain-Reorganisationen** | Steuerbenachrichtigungen für `chain.reorg` ausgegeben; Empfänger verwirft ersetzte Ereignisse vor dem Anwenden kanonischer Replays | Log-Benachrichtigungen tragen `"removed": true` für reorganisierte Logs; `newHeads` erfordert Prüfung des Parent-Hashs | Client verfolgt die Kontinuität der `parentHash`-Kette über Poll-Zyklen hinweg, um Reorgs zu erkennen | | **Wiederherstellung bei Fehlern** | Server-Aufbewahrungsfenster erlaubt Replay über `POST /v1/push/subscriptions/{id}/replay`; Lücken vor dem Aktivierungsblock erfordern `eth_getLogs`-Nachfüllung | Keine serverseitige Warteschlange; Client verbindet sich erneut und füllt verpasste Bereiche per `eth_getLogs` nach, dedupliziert nach `(blockHash, transactionHash, logIndex)` | Setzt Abfragen ab dem gespeicherten `last_synced_block` fort; unterteilt Chunks anhand von `max_logs_block_range` des Netzwerks aus [GET /v1/chains](https://api.blockvectra.com/v1/chains) | | **Abrechnungsmodell** | Tägliche Adressgebühr pro Gruppe, basierend auf der höchsten Adressanzahl während der Online-Zeit am UTC-Tag, zuzüglich CU für zugestellte Datenereignisse; siehe [Webhook-Abrechnung](https://docs.blockvectra.com/de/guides/webhook-push/#billing-and-example) | Handshake und Heartbeats unberechnet; `eth_subscribe` / `eth_unsubscribe` und übertragene Socket-Benachrichtigungseinheiten werden in CU abgerechnet | Abrechnung pro Anfrage in Compute Units: `eth_blockNumber`, `eth_call`, `eth_getLogs`; Methodengewichte und CU pro 1 $ aus [GET /v1/plans](https://console-api.blockvectra.com/v1/plans), unten dargestellt | | **Am besten geeignet für** | Überwachung von Benutzereinzahlungen, Hot-Wallet-Adress-Tracking, Händler-Checkouts, asynchrone Ereignis-Webhooks | Live-`newHeads` und gefilterte `logs`, reaktive Bots, interaktive UIs auf unterstützten Netzwerken | Batch-Abgleich, Cronjobs, ETL-Pipelines, Chains ohne WebSocket-Unterstützung (wie HyperEVM) | **Aktive Umrechnungsparameter** 1 USD = 10,000 Abrechnungseinheiten, 1 Abrechnungseinheit = 1,000 CU (1 USD = 10,000,000 CU). **Formel**: CU-Gewichtung × 1,000,000 ÷ (10,000 × 1,000) USD. | Methode | CU pro Aufruf | Preis pro 1M Aufrufe (USD) | | --- | --- | --- | | `eth_blockNumber` | 1 | $0.10 | | `eth_call` | 15 | $1.50 | | `eth_getLogs` | 30 | $3.00 | | `debug_traceTransaction` | 100 | $10.00 | | `data.block` | 5 | $0.50 | ## Wann Adress-Webhooks zu wählen sind Wählen Sie die [Blockchain Webhook API](https://docs.blockvectra.com/de/guides/webhook-push/), wenn Ihr Backend als Standard-Webdienst betrieben wird, der eingehende HTTPS-Anfragen empfangen kann: * **Große Adresslisten**: Überwachen Sie Einzahlungen oder Abhebungen über Tausende von Kundenadressen hinweg, ohne dauerhafte Sockets pro Wallet aufrechtzuerhalten. * **Serverlose oder containerisierte Empfänger**: Serverlose Funktionen (AWS Lambda, Cloudflare Workers) starten bei eingehenden Webhooks und müssen keine kontinuierlichen Verbindungen aufrechterhalten. * **Automatisierte Wiederholungen und Replay**: Vorübergehende Ausfälle des Empfängers werden durch automatischen Wiederholungs-Backoff abgefedert. Innerhalb des Server-Aufbewahrungsfensters können verpasste Zustellungen über den Replay-Endpunkt erneut zugestellt werden. * **Überlegungen zur Aktivierungsgrenze**: Der Abgleich beginnt erst nach der Anwendung der Abonnementänderung (`applied_from_block`). Ereignisse, die vor dem Hinzufügen einer Adresse oder während des Status `offline` eines Abonnements aufgetreten sind, müssen über historische RPC-Logs abgefragt werden. Prüfen Sie die [Signaturverifizierungs- und Replay-Workflows](https://docs.blockvectra.com/de/guides/webhook-push/#verify-signatures), bevor Sie produktive Webhook-Empfänger bereitstellen. ## Wann WebSocket-Abonnements zu wählen sind Wählen Sie [WebSocket-Abonnements](https://docs.blockvectra.com/de/guides/websocket-subscriptions/), wenn niedrige Latenz erforderlich ist und Ihr Prozess einen langlebigen ausgehenden Socket aufrechterhalten kann: * **Live-Block-Header**: Streamen Sie `newHeads`, sobald jeder Block an die Spitze der Chain angehängt wird. * **Contract-Event-Filter**: Streamen Sie Echtzeit-Contract-`logs`, die einer Adresse oder einem bestimmten `topic0` entsprechen. * **Private Umgebungen**: Ideal für lokale Skripte, CLI-Agenten oder Backend-Dienste hinter NAT oder Firewalls, die keinen eingehenden öffentlichen HTTPS-Port öffnen können. * **Prüfung der Netzwerkverfügbarkeit**: WebSocket wird auf Robinhood Chain unterstützt (Netzwerk-Slug `robinhood_mainnet`, Chain-ID 4663 und `robinhood_testnet`). HyperEVM bietet derzeit keine WebSocket-Unterstützung (`ws: false`); ein Verbindungsversuch per WebSocket zu einer nicht bedienten Chain gibt HTTP 404 zurück ([`unknown_chain`](https://docs.blockvectra.com/de/errors/#unknown_chain)). * **Disziplin bei Verbindungsabbrüchen**: WebSocket-Benachrichtigungen werden bei Verbindungsabbrüchen nicht serverseitig vorgehalten. Wenn der Socket abbricht, müssen Clients die Verbindung mit zufälligem exponentiellem Backoff wiederherstellen und verpasste Blöcke über `eth_getLogs` nachfüllen. Konsultieren Sie den [Leitfaden zu WebSocket-Abonnements](https://docs.blockvectra.com/de/guides/websocket-subscriptions/) für Filterlimits, Verbindungsobergrenzen (20 pro Schlüssel, 50 pro Konto) und viem-Verbindungsbeispiele. ## Wann begrenztes RPC-Polling zu wählen ist Wählen Sie begrenztes JSON-RPC-Polling beim Betrieb von geplanten Workern, Daten-Pipelines oder auf Netzwerken, auf denen WebSocket nicht verfügbar ist: * **Netzwerke ohne WebSocket**: HyperEVM (`hyperevm_mainnet`) bietet derzeit JSON-RPC-HTTP-Zugriff, aber kein WebSocket (`ws: false`). Das Polling von `eth_blockNumber` und das Abfragen von `eth_getLogs` innerhalb unterstützter Blockbereiche ermöglicht die HyperEVM-Ereignisverarbeitung. * **Gesteuertes Abfragetempo**: Polling ermöglicht es Entwicklern und KI-Agenten, die Anfragehäufigkeit zu steuern, den Verbrauch von Compute Units gegenüber Limits pro Schlüssel zu verwalten und Socket-Abbrüche bei lang andauernden Aufgaben zu vermeiden. Limits pro Schlüssel — Standardwerte sind 400 CU/s und Burst 1,600 CU. * **Blockbereichslimits**: Authentifizierte `eth_getLogs`-Abfragen sind durch das `max_logs_block_range` des Netzwerks aus [GET /v1/chains](https://api.blockvectra.com/v1/chains) begrenzt. Das Überschreiten dieses Limits gibt den Fehlercode `-32602` ([`logs_range_too_large`](https://docs.blockvectra.com/de/errors/#logs_range_too_large)) zurück. Teilen Sie breitere Intervalle in aufeinanderfolgende Abschnitte auf, die das `max_logs_block_range` des Zielnetzwerks nicht überschreiten. | Chain | Chain-Slug | max_logs_block_range (Blöcke) | | --- | --- | --- | | Arbitrum One | `arb_mainnet` | 1,000 | | Base | `base_mainnet` | 1,000 | | BNB Smart Chain | `bsc_mainnet` | 1,000 | | Ethereum | `eth_mainnet` | 1,000 | | Ethereum Sepolia | `eth_sepolia` | 1,000 | | HyperEVM | `hyperevm_mainnet` | 1,000 | | Polygon | `polygon_mainnet` | 1,000 | | Robinhood Chain | `robinhood_mainnet` | 1,000 | | Robinhood Chain Testnet | `robinhood_testnet` | 1,000 | Siehe den [HyperEVM-Log-Backfill-Leitfaden](https://docs.blockvectra.com/de/guides/hyperevm-backfill/) und den [Leitfaden zum eth\_getLogs-Blockbereich](https://docs.blockvectra.com/de/guides/getlogs-block-range/) für Chunking-Algorithmen. Für eine vollständige Workload-Checkliste und Selbsttests beginnen Sie mit [Wie Sie einen RPC-Anbieter auswählen](https://docs.blockvectra.com/de/guides/choose-rpc-provider/). Wenn Sie einen Anbieter für Polling mit geringem Volumen wählen, [vergleichen Sie Anbieter hinsichtlich Standard-RPC-Abrechnung und -Abdeckung](https://docs.blockvectra.com/de/guides/quicknode-alternative/). Vergleichen Sie nutzungsbasierte Abrechnung mit Test- und Abonnementkosten; Benachrichtigungs- und Backfill-Kosten nutzen andere Messungen als RPC-Leseoperationen. ## Implementierungsleitfäden ### WebSocket auf Robinhood Chain Für Live-`newHeads` oder gefilterte `logs` auf Robinhood Chain folgen Sie dem [Leitfaden zu WebSocket-Abonnements](https://docs.blockvectra.com/de/guides/websocket-subscriptions/) für Authentifizierung und Abonnementanfragen. Stellen Sie nach einem Verbindungsabbruch die Verbindung mit Backoff wieder her, abonnieren Sie erneut und füllen Sie verpasste Blöcke von einem gespeicherten Cursor aus mit `eth_getLogs` nach; deduplizieren Sie Logs anhand von `(blockHash, transactionHash, logIndex)`. ### Begrenztes Polling auf HyperEVM Für HyperEVM (`hyperevm_mainnet`) folgen Sie dem [HyperEVM-Log-Backfill-Leitfaden](https://docs.blockvectra.com/de/guides/hyperevm-backfill/) für begrenztes Polling und Wiederherstellung. Fragen Sie vom gespeicherten Cursor aus in Abschnitten innerhalb von `max_logs_block_range` ab, speichern Sie Ereignisse und Fortschritt nach erfolgreicher Verarbeitung gemeinsam dauerhaft und wiederholen Sie unvollständige Bereiche. Prüfen Sie die Chain-Kontinuität und scannen Sie überlappende Bereiche, um Reorgs zu behandeln. ## Nächste Schritte * [Datensatzverzeichnis durchsuchen](https://blockvectra.com/de/data/), um alle von BlockVectra indexierten Datensätze zu sehen. * [Kostenlosen Tarif und Preise ansehen](https://blockvectra.com/de/pricing/#free), um zu prüfen, was Ihr Konto beinhaltet. * [In der Konsole anmelden](https://console.blockvectra.com/login/?next=%2Fkeys%2F), um einen API-Schlüssel zu erstellen.