Zum Inhalt springen

Blockchain Webhook API für Wallet-Aktivität und Token-Transfers

Adress-Webhooks senden Transfers überwachter Wallets und übereinstimmende Contract-Logs an Ihren HTTPS-Empfänger; prüfen Sie Signaturen, deduplizieren Sie Ereignisse und behandeln Sie Lücken, bevor Sie eine Zahlung gutschreiben.

Ereignisse vor dem Aktivierungsblock einer Adresse müssen separat historisch abgefragt werden; replay kann sie nicht wiederherstellen. Interne Transfers nativer Coins sind ausgeschlossen. Bestätigungen müssen im Bereich jeder Chain aus GET /v1/push/chains liegen und zählen Blöcke, keine safe- oder finalized-Tags.

Adressaktivität an Ihren Endpoint zustellen

native.transfer liefert native Transfers aus Transaktionen auf oberster Ebene; token.transfer liefert ERC-20-, ERC-721- und ERC-1155-Transfers. log liefert andere Logs, deren ausgebender Contract oder topics[1]–topics[3] eine beobachtete Adresse enthalten.

GET /v1/push/chains gibt aktuell unterstützte Chains und ihre Bestätigungsgrenzen zurück. Fragen Sie diese mit Ihrem API key ab, bevor Sie Chains für ein Abonnement auswählen.

Ein Abonnement umfasst mehrere Chains mit einer Empfangs-URL. Entwickler und AI Agents haben dieselben Kapazitätsoptionen und Preise.

Self-Service

Bis zu 1,000,000 Adressen pro Abonnement. Nach der Registrierung verfügbar.

Nutzungsabhängige Standardtarife

Enterprise

10,000,000 / 100,000,000 Adressen pro Abonnement.

Zur Freischaltung kontaktieren

Für beide Stufen gelten dieselben Tarife pro Adresstag und zugestelltem Ereignis.

Wallet- und Contract-Aktivität nutzen

Wallet-Aktivität

Beobachten Sie Wallet-Adressen für ein- und ausgehende native Transfers und Token-Transfers.

Stablecoin-Zahlungen

Empfangen Sie ERC-20-Transfers von USDT / USDC und prüfen Sie Token-Contract, Empfänger und ganzzahligen Betrag vor der Gutschrift.

Contract-Ereignisse

Beobachten Sie eine Contract-Adresse für deren Logs oder empfangen Sie Logs mit einer beobachteten Adresse in topics[1]–topics[3].

NFT-Transfers

Verarbeiten Sie ERC-721- und ERC-1155-Transfers mit token_id und bei Batch-Transfers auch batch_index.

USDT- / USDC-Zahlungsüberwachung

Ereignisse prüfen, bestätigen und wiederherstellen

  • Prüfen Sie vor der Verarbeitung von Ereignissen die HMAC-SHA256-Signatur über `webhook-id.webhook-timestamp.raw-body` mit dem Geheimnis des Abonnements; verwenden Sie den unveränderten Request-Body und parsen Sie JSON nicht vorab.
  • Die Zustellung erfolgt mindestens einmal. Deduplizieren Sie anhand der Ereignis-id und antworten Sie nach dauerhafter Speicherung des Verarbeitungsergebnisses mit 2xx. Fehlgeschlagene Zustellungen werden wiederholt, solange das Abonnement online und das Ereignis innerhalb der Aufbewahrungsfrist ist.
  • Setzen Sie confirmations pro Chain innerhalb der Grenzen von GET /v1/push/chains. chain.reorg meldet ersetzte Blöcke: Markieren Sie alte Ereignisse anhand von ref, behalten Sie automatisch erneut zugestellte Ereignisse der kanonischen Chain und deduplizieren Sie anhand von id.
  • Replay stellt gespeicherte Treffer innerhalb des zulässigen Bereichs erneut zu. Aktivität vor dem Hinzufügen einer Adresse oder Chain zum Abonnement wird nicht abgerufen.

Preise

Die Tabelle zeigt CU-Gewichte und das kostenlose Adresskontingent aus GET /v1/plans. Datenereignisse werden pro Zustellung berechnet; automatische Wiederholungen und Steuerereignisse sind kostenlos. Replay-Zustellungen kosten den Ereignistarif.

Webhook-Push

CU-Gewichte aus GET /v1/plans. Automatische Wiederholungen sind kostenlos.

Kostenlose Adressen pro Konto und UTC-Tag: 1000

Das kostenlose Adresskontingent pro Konto und UTC-Tag wird unabhängig vom Tarif von allen Abonnementgruppen geteilt. Für jede Gruppe zählt die maximale Adressanzahl während ihrer Online-Zeit an diesem Tag; das Kontingent wird in aufsteigender Gruppen-ID-Reihenfolge verteilt. Dieselbe Adresse in zwei Gruppen zählt zweimal; die Anzahl der Chains einer Gruppe vervielfacht ihre Adressanzahl nicht. Eine Gruppe, die den gesamten Tag offline oder gelöscht ist, trägt nichts bei. Für jede Gruppe wird die nach Abzug ihres Kontingentanteils verbleibende Anzahl mit dem CU-Gewicht `push.address_day` in `method_weights` multipliziert. Das aktuell konfigurierte Kontingent stammt aus derselben Preispolitik wie die Adresstaggebühr; es ist weder ein Kapazitätslimit des Kontos noch ein separates Kontingent pro Gruppe.

MethodeAbrechnungseinheitCU
push.address_dayAbrechenbarer Adresstag33
push.historyErfolgreiche Verlaufsabfrage25
push.logZugestelltes Datenereignis150
push.native_transferZugestelltes Datenereignis150
push.token_transferZugestelltes Datenereignis150
Preise

Empfänger anbinden