Migration von SparkPost

Nutzen Sie diese Anleitung, um ausgehende E-Mails von SparkPost zu Bird zu migrieren. Folgen Sie der Haupt-Migrations-Checkliste und verwenden Sie die folgenden Zuordnungen für Ihre HTTP- oder SMTP-Integration.

Bevor Sie beginnen

Sie benötigen Zugriff auf Ihr SparkPost-Konto und Ihre Subaccounts, das DNS der Sende-Domain, die Anwendungskonfiguration und den Webhook-Handler. Richten Sie einen Bird-Workspace und einen API-Schlüssel in Ihrer gewählten Region ein. Der Opt-out-Import erfordert außerdem preferences-Schreibberechtigung auf dem Schlüssel.

Inventarisieren Sie Absender, Templates, Snippets, Empfängerlisten, Unterdrückungen, geplante Sendungen, IP-Pools und Webhooks. Berücksichtigen Sie SDKs, Framework-Mail-Adapter, Hintergrundjobs und eingehende E-Mail-Flows. Notieren Sie neue Ressourcen-IDs, sobald Sie sie erstellen; SparkPost-IDs und -Anmeldedaten funktionieren in Bird nicht. Verwenden Sie die Bird-SDKs als Ersatz für einen SparkPost-Client, und prüfen Sie dessen Retries, Timeouts und Paginierung.

Wenn Sie SparkPost-Subaccounts verwenden, kontaktieren Sie uns, bevor Sie ein Workspace-Layout wählen. Bestätigen Sie die verfügbaren Workspaces, Berechtigungen, gemeinsam genutzten Ressourcen und den Workflow zur Mandantenbereitstellung. Ein Workspace-API-Schlüssel kann Mandanten nicht per X-MSYS-SUBACCOUNT wechseln. Bewahren Sie gesperrte Mandanten und mandantenspezifische Sendebeschränkungen während der Migration.

Bestätigen Sie, dass Ihre Bird-Plankontingente und Anfragerate-Begrenzungen Ihr Sendevolumen, Ihre Ressourcenanzahl und Ihren Spitzenverkehr abdecken.

Registrieren Sie Ihre Sende-Domains frühzeitig. Bewahren Sie funktionierendes SparkPost-DNS und wählen Sie bei Bedarf separate Return-Path- und Tracking-Hostnamen. Wenn die Registrierung einen Eigentümerkonflikt meldet, kontaktieren Sie den Support, bevor Sie eine aktive Domain entfernen.

Dedizierte IPs: Kontaktieren Sie uns oder Ihr Account-Team vor der Migration. Bitten Sie uns zu bestätigen, ob Ihre bestehenden SparkPost-IPs zu Bird übertragen werden können, und stimmen Sie Pool-Einrichtung, Zeitplan und eventuell nötiges Warmup ab. Geben Sie Ihre Kontoregion, IP-Adressen, Pool-Namen und Ihr Sendevolumen an. Halten Sie Ihre aktuellen IPs aktiv, bis der Migrationsplan bestätigt ist.

Bestätigen Sie die Pool-Auswahl und die IP- oder Hostname-Allowlists der Empfänger vor dem Cutover. Der Kauf einer IP ändert nicht den Standard-Pool. Neu erworbene IPs können während des Warmups Überlauf über die gemeinsame Infrastruktur senden, was relevant ist, wenn Empfänger E-Mails nur von bestimmten IPs akzeptieren.

Übergeben Sie dies Ihrem Agenten

Fügen Sie dies in Ihren Coding-Agenten in Ihrem Anwendungs-Repository ein:

Help me migrate my SparkPost email integration to Bird.
1. Use an existing Bird MCP connection or signed-in CLI. Otherwise follow https://bird.com/docs/ai/set-up-your-agent.md. Append .md to Bird docs URLs to read Markdown.
2. Read https://bird.com/docs/guides/email/migrate/sparkpost.md and https://bird.com/docs/guides/email/migrate.md. Make a read-only inventory of my SparkPost call sites, SDKs, resource IDs, configured URLs, sending domains, and scheduled jobs before editing. Never print API keys.
3. Propose workspace and region mappings. If subaccounts, dedicated IPs, or domain ownership conflicts need a migration plan, use the available Bird tools to open a human email support ticket and return its ID. For CLI usage, read https://bird.com/docs/cli/reference/support-tickets-create.md. Wait for the agreed plan before moving those resources.
4. Follow https://bird.com/docs/guides/email/sending-domains.md; preserve working DNS and show me proposed records. Ask before DNS changes or paid provisioning.
5. Port sending, templates, and webhooks using this guide. Preserve recipient privacy, personalization, and categories. Export suppressions with scope and type; show me the handling before importing or changing preferences.
6. Test using https://bird.com/docs/guides/email/testing-sandbox.md. Show me results and unresolved differences, including tracking, signatures, and correlation.
7. Ask for explicit approval before production cutover. Keep a rollback path; get separate approval before retiring SparkPost resources or credentials.

Sende-Aufruf zuordnen

Ersetzen Sie POST /api/v1/transmissions durch POST /v1/email/messages oder POST /v1/email/batches für unabhängige Nachrichten. Die SparkPost-API-Übersicht listet die regionalen Hosts und die Authentifizierung auf. Bird verwendet https://us1.platform.bird.com oder https://eu1.platform.bird.com, passend zur Region Ihres API-Schlüssels, mit Authorization: Bearer $BIRD_API_KEY.

Eine SparkPost-Transmission kann separate, personalisierte E-Mails für ihre Empfänger erzeugen. Bird teilt Inhalt und Parameter über die Empfänger eines einzelnen Versands. Verwenden Sie eine separate Nachricht pro Personalisierung, optional gruppiert in einem Batch. Reine To-Versendungen bleiben einzeln adressiert; prüfen Sie die sichtbaren Header, wenn Sie Cc-/Bcc-Kopien hinzufügen.

Ordnen Sie die SparkPost-Transmission-Felder zu:

Für To/Cc/Bcc-Kopien einer E-Mail erstellen Sie die Empfängergruppe einmalig neu. SparkPosts angezeigte Adressen können von den Zustellempfängern abweichen; Birds to, cc und bcc fügen jeweils Zustellempfänger hinzu. Das Kopieren eines SparkPost-CC-Headers in das cc jeder expandierten Nachricht kann doppelte Kopien versenden. Prüfen Sie sichtbare Header und Empfängeranzahlen vor der Umstellung.

Prüfen Sie Sendefeld-Limits, Zeitplanung und Anhangregeln. Aktualisieren Sie Inline-Bild-IDs und zugehörige cid:-Referenzen gemäß den Regeln von Bird. Konfigurieren Sie den Return-Path und die Tracking-Domain auf der Domain.

Die HTTP-Sendefelder von Bird enthalten nicht SparkPosts content.email_rfc822, content.amp_html oder options.inline_css. Erstellen Sie Rohnachrichten mit den unterstützten Feldern neu, stellen Sie HTML/Text-Fallbacks für AMP bereit und inlinen Sie CSS vor dem Einreichen von HTML. SMTP parst und erstellt unterstützte Nachrichtenteile neu; validieren Sie die empfangene MIME, wenn Sie von deren exakter Struktur abhängen. MIME-Parameter von Anhängen wie Kalender-method oder Text-charset bleiben nicht erhalten.

Für geplante API-Nachrichten fixiert Bird die Template-Version, Sprache und Parameter bei Annahme der Anfrage. Spätere Template-Änderungen aktualisieren diese Nachricht nicht. Um sie zu ändern, stornieren Sie die geplante Nachricht, bevor die Verarbeitung beginnt, und reichen Sie einen Ersatz ein. Bewahren Sie eine Gruppe von Bird-Nachrichten-IDs auf, wenn Sie SparkPosts kampagnenbasierte Stornierung ersetzen müssen.

Setzen Sie BIRD_API_KEY auf Ihren Bird-Key. Dieses Sandbox-Beispiel benötigt keine verifizierte Domain und erreicht keinen echten Posteingang. Für einen EU-Key verwenden Sie https://eu1.platform.bird.com:

curl --fail-with-body https://us1.platform.bird.com/v1/email/messages \
  -H "Authorization: Bearer $BIRD_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "onboarding@messagebird.dev",
    "to": ["delivered@messagebird.dev"],
    "subject": "Your receipt",
    "text": "Thanks for your order, {{ first_name }}.",
    "parameters": {"first_name": "Alex"},
    "category": "transactional",
    "metadata": {"order_id": "order_123"},
    "tags": [{"name": "mailstream", "value": "receipts"}]
  }'

Erwarten Sie 202 Accepted und eine em_-Nachrichten-ID. Speichern Sie diese ID und verfolgen Sie Empfängerergebnisse über Events. Annahme bedeutet nicht Zustellung: Ein unterdrückter Empfänger kann angenommen und später abgelehnt werden. Aktualisieren Sie das Response-Parsing, die Fehlerbehandlung und die idempotenten Wiederholungsversuche zusammen mit dem Sendeaufruf.

Lesen Sie bei einem Batch das data-Array aus und speichern Sie die ID jeder Nachricht zusammen mit Ihrem eigenen Sendedatensatz. Bird validiert den Batch vor dem Einreihen in die Warteschlange: Eine ungültige Nachricht kann dazu führen, dass die gesamte Anfrage abgelehnt wird. Teilen Sie große Übertragungen auf, damit sie die Batch-Limits einhalten, und befolgen Sie die Retry-Regeln von Bird, wenn eine Antwort mehrdeutig ist.

Vergeben Sie für jede einzelne Anfrage oder jeden Batch-Abschnitt einen eigenen stabilen Idempotenz-Schlüssel. Das Replay-Fenster von Bird unterscheidet sich von dem bei SparkPost; bewahren Sie Ihre Sendedatensätze über dieses Fenster hinaus auf, um Duplikate während des Cutover oder Rollback zu vermeiden.

SMTP-Absender migrieren

Verwenden Sie die SMTP-Verbindungseinstellungen von Bird, den Benutzernamen bird und einen API-Schlüssel mit aktiviertem E-Mail-Versand. Prüfen Sie die Region, TLS und die Schlüsselkonfiguration.

Konvertieren Sie SparkPosts X-MSYS-API-Optionen, bevor Sie den Header entfernen. Legen Sie Kategorie, Tags, Tracking und Pool-Standardwerte in der SMTP-Konfiguration von Bird fest. Diese Einstellungen gelten pro API-Schlüssel; verwenden Sie separate konfigurierte Schlüssel oder HTTP, wenn sie zwischen Nachrichten variieren. Verwenden Sie HTTP für nachrichtenspezifische Metadaten oder Template-Parameter.

Setzen Sie jeden Zustellungsempfänger in den SMTP-Envelope, sichtbare Empfänger in die MIME-Header To/Cc und Bcc-Empfänger ausschließlich in den Envelope. Inventarisieren Sie X-MSYS-API.archive separat: SparkPost-Archivkopien behalten die Tracking-URLs des ursprünglichen Empfängers bei, daher ist gewöhnliches Bcc nicht gleichwertig. Validieren Sie einen Ersatz, bevor Sie diesen Ablauf umstellen.

Übernehmen Sie Ihre wirksamen Tracking-Einstellungen explizit: Ein unkonfigurierter SMTP-Schlüssel von Bird aktiviert Open- und Click-Tracking, während die SparkPost-Standardwerte je nach Account variieren. Setzen Sie auch die Kategorie: Bird SMTP verwendet standardmäßig transaktional und Inline-HTTP standardmäßig Marketing. Newsletter-Absender benötigen marketing auf beiden Wegen.

Verwenden Sie bei SMTP-Retries denselben Idempotenz-Schlüssel, Envelope und exakt dieselben MIME-Bytes. Eine Neugenerierung von Date, Message-ID oder MIME-Boundaries ändert den Payload und kann einen sicheren Retry verhindern.

Templates konvertieren

Exportieren Sie die Versionen, die Sie tatsächlich über SparkPosts Templates-API versenden: Listen Sie mit GET /api/v1/templates?draft=false auf und rufen Sie den Inhalt mit GET /api/v1/templates/{id}?draft=false ab. Speichern Sie Entwürfe bei Bedarf separat. Nehmen Sie mit Subaccounts geteilte Templates und referenzierte Snippets in das Inventar auf.

SparkPosts Template-Sprache und die Liquid-Syntax von Bird unterscheiden sich. Konvertieren Sie Bedingungen, Schleifen, Standardwerte und verschachtelte Werte. Lösen Sie Empfänger-Overrides und für das Rendering verwendete Metadaten in explizite Parameter auf. Zum Beispiel wird {{ if ... }} zu {% if ... %}. Gemeinsame {{ name }}-Syntax allein stellt keine Kompatibilität her.

Expandieren Sie Snippets vor der Veröffentlichung; das Liquid von Bird unterstützt weder include noch render. Ersetzen Sie bei gespeicherten Templates externe Referenzen wie {{ user.name }} durch flache Parameter wie {{ user_name }}. Wenn Sie dynamisches HTML über SparkPost-Parameter einfügen, rendern Sie es in Ihrer Anwendung und übermitteln Sie den fertigen Body ohne Inline-parameters; gewöhnliche HTML-Parameterwerte werden escaped.

Erstellen, prüfen und veröffentlichen Sie ein Bird-Template und folgen Sie dann Senden mit einem Template. Übernehmen Sie den effektiven Absender, Reply-To und benutzerdefinierte Header aus SparkPost in die Sendeanfrage; Bird-Templates liefern den Inhalt.

Für Inline-Liquid geben Sie parameters an, auch {}; ohne diese Angabe bleiben Tokens unverändert. Prüfen Sie fehlende Werte, Escaping und URLs.

Ersetzen Sie Abmelde-Platzhalter durch {{ bird.unsubscribe_url }}. Bird liefert Marketing-Abmelde-Header; entfernen Sie benutzerdefinierte List-Unsubscribe- und List-Unsubscribe-Post-Header aus Marketing-Sendungen, um eine 422-Ablehnung zu vermeiden.

Die Abmelde-Links von Bird melden die Adresse workspace-weit von Marketing-E-Mails ab. Diese Links bieten keine listenspezifischen Abmeldungen. Prüfen Sie dieses Verhalten, wenn Ihre SparkPost-Integration separate Abonnements anbietet.

Empfängerlisten migrieren

Exportieren Sie jede gespeicherte Empfängerliste mit GET /api/v1/recipient-lists/{id}?show_recipients=true, um Mitgliedschaft und Personalisierung einzuschließen. Erstellen Sie Ziel-Audiences und registrieren Sie Kontakteigenschaften vor dem Import. Prüfen Sie jedes Importergebnis und gleichen Sie die Mitgliederzahlen ab.

Kontakteigenschaften gehören zum Kontakt über alle seine Audiences hinweg. Wenn dieselbe Adresse in mehreren SparkPost-Listen unterschiedliche Substitutionsdaten hat, gleichen Sie diese Werte vor dem Import ab, um ein Überschreiben zu vermeiden. Bird-Kontakteigenschaften haben skalare Typen; behalten Sie listenspezifische oder strukturierte Personalisierung in Ihrer Anwendung, wenn sie nicht sicher abgebildet werden kann.

Verwenden Sie Broadcasts, wenn ein veröffentlichtes Template aus Kontakteigenschaften befüllt werden kann. Die Audience-Mitgliedschaft wird beim Sendestart aufgelöst, und die Sende- und Parallelitätskontingente für Broadcasts gelten. Verwenden Sie unabhängige Batch-Nachrichten für anfragespezifische Parameter oder einen festen Empfänger-Snapshot. Validieren Sie Einwilligung und Unterdrückungsverarbeitung, bevor Sie eine migrierte Liste aktivieren.

Unterdrückungen exportieren

Exportieren Sie vor dem Produktionsversand. Beginnen Sie mit GET /api/v1/suppression-list?cursor=initial&types=transactional,non_transactional,open_tracking und folgen Sie dann der Paginierung bis zum Abschluss. Speichern Sie die vollständigen Datensätze einschließlich Typ, Quelle, Listen-ID, Subaccount und Zeitstempel. Verwenden Sie X-MSYS-SUBACCOUNT: 0 für das Hauptkonto und die jeweilige Subaccount-ID für dessen eigene Liste. Siehe SparkPosts Suppression List API.

Klassifizieren Sie Datensätze nach Typ, Quelle und Geltungsbereich, bevor Sie die Importschleife des Hauptleitfadens verwenden. Birds POST /v1/email/suppressions nimmt eine email entgegen und erstellt eine manuelle, workspace-weite Sperre für beide Kategorien:

• Vom E-Mail-Empfang gesperrte Adressen: Importieren Sie diejenigen, die kategorieübergreifend gesperrt werden sollen. Bewahren Sie den Originalexport für den Abgleich auf; importierte Datensätze tragen den manuellen Grund von Bird.
• Kontoweite Marketing-Abmeldungen: Verwenden Sie POST /v1/preferences mit channel: "email", der Adresse in handle, status: "revoked" und coverage: "non_transactional". Setzen Sie source: "sparkpost-migration" für den Abgleich. Prüfen Sie zuerst vorhandene Bird-Präferenzen und bewahren Sie strengere Einschränkungen; kontrollieren Sie applied und die zurückgegebene Präferenz nach jedem Schreibvorgang.
• Listen-spezifische oder rein transaktionale Einschränkungen: Bewahren Sie deren Geltungsbereich in der Sendeberechtigungslogik Ihrer Anwendung. Die E-Mail-Präferenzen von Bird gelten kanalweit und können diese Geltungsbereiche nicht abbilden. Eine manuelle Unterdrückung kann auch Passwortrücksetzungen blockieren. Halten Sie betroffenen Versand an, bis Sie den Ersatz verifiziert haben.
• Open-Tracking-Abmeldungen: Setzen Sie track_opens: false für die unabhängige Nachricht, zusätzlich zu etwaigen Sendeeinschränkungen. Für SMTP verwenden Sie einen Schlüssel mit deaktiviertem Open-Tracking oder nutzen Sie HTTP für nachrichtenspezifische Steuerung.

Die obige Präferenzanfrage erfasst die Einschränkung zum Importzeitpunkt. Behalten Sie die ursprünglichen Zeitstempel von SparkPost in Ihrem Export und gleichen Sie spätere Einwilligungen ab, bevor Sie schreiben. Gleichen Sie importierte Datensätze und fehlgeschlagene Schreibvorgänge ab und testen Sie dann beide Kategorien. Synchronisieren Sie neue Abmeldungen und Unterdrückungen, solange beide Anbieter senden. Wenden Sie Abmeldungen aus zuvor über SparkPost zugestellten E-Mails auch nach der Umstellung weiterhin auf Bird an. Siehe Unterdrückungen für die native Bounce- und Beschwerdebehandlung.

Webhook-Events übersetzen

SparkPost sendet gebündelte Webhook-Events in msys-Wrappern. Bird liefert ein Event pro Anfrage mit type, timestamp und data. Registrieren Sie einen Bird-Endpoint mit expliziten Event-Abonnements und Signaturverifizierung. Halten Sie den SparkPost-Handler für den verbleibenden Datenverkehr aktiv.

Direkte API- und SMTP-Sends lösen email.accepted vor der Verarbeitung aus. Broadcasts protokollieren die Annahme in den Events API und im E-Mail-Log, lösen diesen Webhook aber nicht aus. SparkPosts policy_rejection, generation_failure und generation_rejection werden auf email.rejected abgebildet; prüfen Sie rejection_reason. Deduplizieren Sie Öffnungen separat, wenn Sie eindeutige Interaktionen zählen.

Verwenden Sie data.email_id und data.recipient_id für die Bird-Korrelation und übergeben Sie Ihre eigenen Kennungen in metadata. Ersetzen Sie SparkPosts Batch-ID-Handling durch Birds Regeln für Webhook-Deduplizierung und -Reihenfolge. Lesen Sie Bounce-Details, bevor Sie entscheiden, ob eine Adresse unterdrückt werden soll; die Bounce-Klassifizierung unterscheidet permanente Adressfehler von temporären oder richtlinienbedingten Fehlern.

Reporting-Verlauf beibehalten

Exportieren Sie den SparkPost-Event-Verlauf und die aggregierten Berichte, die Sie benötigen, bevor deren Aufbewahrungszeiträume ablaufen. Folgen Sie der Event-Paginierung bis zum Ende und bewahren Sie Provider-IDs, Account-/Subaccount-Zuordnung, Zeitstempel und Reporting-Filter auf. Sammeln Sie während der Überlappungsphase weiterhin verspätete Events und archivieren Sie den SparkPost-Verlauf separat.

Speichern Sie eine Baseline für jeden Sende-Stream. Vergleichen Sie übereinstimmende Empfängerpopulationen und Berichtszeiträume und prüfen Sie die Metrikdefinitionen: Provider-Annahme, Zustellung am Empfängerserver, eindeutige Interaktionen und vorab abgerufene Öffnungen sind unterschiedliche Messgrößen. Gleiche Metriknamen allein ergeben keine vergleichbaren Raten.

Eingehende E-Mails separat migrieren

Wenn Sie SparkPost-Relay-Webhooks nutzen, folgen Sie für diesen Ablauf der Anleitung E-Mails empfangen. Der email.received-Webhook von Bird liefert eine inbound_message_id; rufen Sie Body, Anhänge oder das rohe MIME über die API ab, statt die vollständige Nachricht im Webhook zu erwarten. Testen Sie Ihren Handler mit einer Bird-Weiterleitungsadresse und bereiten Sie dann den Domain-Empfang vor, bevor Sie die MX-Einträge ändern. Prüfen Sie das Antwort-Routing nach der DNS-Änderung und archivieren Sie Inhalte, die Sie über die Empfangs-Aufbewahrungsfrist von Bird hinaus benötigen.

Prüfen und umstellen

1. Prüfen Sie die Sendefähigkeit jeder Domain. Führen Sie den Sandbox-Smoke-Test und Beschwerdefälle durch. Stellen Sie sicher, dass signierte Events Ihren Handler erreichen, der richtigen Nachricht zugeordnet werden und doppelte Zustellungen korrekt behandelt werden. Sandbox-Events belegen weder Inbox-Zustellung noch Rendering oder Tracking.
2. Senden Sie von Ihrer verifizierten Domain an kontrollierte echte Postfächer. Prüfen Sie Personalisierung, To/Cc/Bcc-Sichtbarkeit, Anhänge, Authentifizierung und Tracking. Testen Sie eine Abmeldung: Marketing muss stoppen, während berechtigte Transaktions-E-Mails weiterhin zugestellt werden. Testen Sie separat, dass kategorieübergreifende Sperren beide ablehnen. Halten Sie diese Prüfungen von simulierten Sandbox-Ergebnissen getrennt.
3. Weisen Sie ausstehende geplante Sendungen einem Anbieter zu. Leeren oder stornieren Sie das Original, bevor Sie es anderswo neu anlegen. Führen Sie in Ihrer Anwendung Buch darüber, welcher Anbieter jeden logischen Sendevorgang angenommen hat, damit Wiederholungsversuche oder Rollbacks keine zweite Kopie senden.
4. Verlagern Sie einen kontrollierten Teil des Datenverkehrs und überwachen Sie Zustellmetriken und Webhook-Verarbeitung. Folgen Sie bei dedizierten IPs dem mit unserem Team vereinbarten Migrationsplan, einschließlich eines etwaigen Warmups. Erhöhen Sie den Datenverkehr, nachdem die beobachteten Ergebnisse Ihre Zustellanforderungen erfüllen.
5. Falls die Validierung fehlschlägt, pausieren Sie den betroffenen Bird-Datenverkehr und leiten Sie neue Sendungen über den beibehaltenen SparkPost-Pfad mit aktuellen Opt-outs. Klären Sie uneindeutige Sendungen, bevor Sie sie erneut versuchen. Setzen Sie alte Zugangsdaten, Webhooks und DNS erst außer Betrieb, nachdem Warteschlangen und verspätete Events berücksichtigt sind; halten Sie alte Tracking- und Abmeldelinks für bereits zugestellte E-Mails funktionsfähig.

Falls die Authentifizierung fehlschlägt, prüfen Sie das Bird-Bearer-Token und die Region. Falls Präferenz-Importe 403 zurückgeben, prüfen Sie die preferences-Schreibberechtigung des Keys, bevor Sie fortfahren. Falls Personalisierung falsch gerendert wird, überprüfen Sie die Liquid-Konvertierung und die Parameter. Falls Transaktions-E-Mails unerwartet abgelehnt werden, prüfen Sie importierte manuelle Unterdrückungen. Verwenden Sie das E-Mail-Log und die Event-Details, um jede Korrektur zu verifizieren.

Nächste Schritte

• E-Mails senden: Payload-Felder, Personalisierung und asynchrone Ergebnisse
• E-Mail-Templates: Vorschau, Veröffentlichung und Liquid-Unterstützung
• Unterdrückungen: Unterdrückungsgründe und Verwaltung
• Webhooks und Events: Signaturen, Wiederholungsversuche und Replay