Affiliate-Webhook

Ein Affiliate-Webhook ist eine HTTP-Benachrichtigung, die an ein anderes System gesendet wird, wenn ein Ereignis im Zusammenhang mit Affiliates eintritt, etwa eine Conversion, eine Provisionsaktualisierung oder eine Änderung des Auszahlungsstatus. Für verwandte Integrationen können ein Callback oder Postback verwendet werden. Die unterstützten Auslöser und Nutzdaten hängen von der Plattform ab.

Begriffe: Webhook, Callback und Postback

Diese Bezeichnungen überschneiden sich je nach Plattform. Ein Webhook ist eine ereignisgesteuerte HTTP-Benachrichtigung. Callback ist ein weiter gefasster Begriff für eine Antwort oder Benachrichtigung an ein anderes System. Bei Affiliate-Integrationen bezeichnet Postback häufig ein serverseitig übermitteltes Conversion-Ereignis. Die Richtung allein ermöglicht keine allgemeingültige Unterscheidung.

Beispiele für Ereignisse und Aktionen des Empfängers

Dies sind konzeptionelle Beispiele und keine Zusicherung, dass jede Plattform diese Auslöser bereitstellt. Prüfen Sie den tatsächlichen Ereigniskatalog und die Version der Nutzdaten, bevor Sie den Empfänger entwerfen.

Webhooks und Polling im Vergleich

Beim Polling wird eine API regelmäßig nach Änderungen abgefragt. Webhooks senden unterstützte Ereignisse, sobald sie eintreten. Webhooks können wiederholte API-Abfragen reduzieren, während Polling oder ein Abgleich dabei helfen können, fehlende Zustände wiederherzustellen. Eine robuste Integration kann beides verwenden, statt anzunehmen, dass Benachrichtigungen vollständig und geordnet eintreffen.

Beispiel für eine doppelte Benachrichtigung

Nach einer Zeitüberschreitung wird ein Genehmigungsereignis zweimal zugestellt. Der Empfänger erkennt dieselbe Ereignis-ID und erfasst nur einen Zustandsübergang. Eine spätere Rückerstattung ist ein anderes Ereignis, das weiterhin verarbeitet werden muss, obwohl es dieselbe Transaktion betrifft.

Deshalb kann es falsch sein, jeden Webhook ausschließlich anhand der Transaktions-ID zu deduplizieren. Ereignis-ID und Transaktions-ID erfüllen unterschiedliche Zwecke.

Betriebliche Prüfungen

Halten Sie Zugangsdaten aus öffentlichen Beispielen heraus, protokollieren Sie Zustellergebnisse ohne unnötige Kundendaten und richten Sie bei wiederholten Fehlern Warnmeldungen ein. Ein Empfänger sollte Anfragen gemäß dem dokumentierten Protokoll des Absenders bestätigen und finanzielle Auswirkungen sicher verarbeiten. Gleichen Sie wichtige Zustände mit der maßgeblichen Plattform ab, statt sich allein auf den Eingangszeitpunkt der Benachrichtigung zu verlassen.

Einen Empfänger für reale Zustellbedingungen entwerfen

Klären Sie, welches Ereignis die Benachrichtigung auslöst und ob es sich auf eine erfasste, genehmigte oder ausgezahlte Provision bezieht. Speichern Sie die Ereignis-ID und die relevante Entitäts-ID, validieren Sie die Anfrage mit der vom Absender unterstützten Authentifizierung und stellen Sie Aufgaben, die nicht schnell abgeschlossen werden können, in eine Warteschlange.

Planen Sie doppelte, verzögerte, fehlgeschlagene und nicht in der richtigen Reihenfolge eintreffende Ereignisse ein. Bei einem Wiederholungsversuch sollte derselbe Datensatz aktualisiert werden, statt einen Bonus zweimal auszuzahlen. Wenn eine Genehmigung vor dem lokalen Verkaufsdatensatz eintrifft, rufen Sie den fehlenden Zustand ab oder gleichen Sie ihn ab, statt die Eingangsreihenfolge als Geschäftsregel zu behandeln.

Die offizielle Webhook-Dokumentation von Stripe beschreibt Muster für die Zustellung und den Entwurf von Endpunkten; Signaturen und Nutzdaten sind Stripe-spezifisch. Verwenden Sie für tatsächliche Felder, unterstützte Auslöser und Authentifizierung die Dokumentation der Affiliate-Plattform. Testen Sie fehlgeschlagene Antworten und den Abgleich, bevor Sie einen Webhook mit einer finanziellen Aktion verknüpfen.

Die entsprechenden Einstellungen in Post Affiliate Pro finden Sie in der Dokumentation zu Webhook-Callbacks . Prüfen Sie Konfiguration und Integrationsanforderungen anhand der Regeln Ihres Programms.

Ablauf auf einen Blick