​

Checkliste für den Produktions-Go-Live

Der Quickstart nennt in Schritt 5 die beiden harten Gates für den Live-Verkehr (KYC-Freigabe und ein aufgeladenes Guthaben). Diese Checkliste bündelt alles Weitere – Live-Schlüssel, Rufnummern-Bereitschaft, Webhooks, Leitplanken, Sicherheit und Compliance – auf einer Seite, die Sie vor dem Launch mit Ihrem Team durchgehen können. Weisen Sie vor dem Start jeder Checkbox einen Verantwortlichen zu. Die Launch-Freigabe unten bedeutet, dass die benannte Person es bestätigt hat – nicht nur, dass „irgendjemand” es geprüft hat.

​

1. Sandbox-Abnahme

Belegen Sie Ihre Integration Ende zu Ende in der Sandbox, bevor Sie Live-Verkehr anfassen.

• Sandbox-Sendungen funktionieren auf jedem Kanal, den Sie nutzen werden. Führen Sie SMS-, WhatsApp-, E-Mail- und/oder Sprachsendungen mit Ihrem dv_test_sk_-Schlüssel aus. Verantwortlich: Engineering.
• Die Production-Endpunkte sind mit Live-Schlüsseln gespiegelt. Derselbe Request-Aufbau funktioniert für dv_test_sk_ und dv_live_sk_; bestätigen Sie, dass nichts den Sandbox-Schlüssel hartkodiert. Verantwortlich: Engineering.
• Ein Zustellungs-Webhook empfängt und protokolliert Sandbox-Quittungen. Behandeln Sie Duplikate (Orbit kann wiederholen) und ignorieren Sie Status außerhalb der Reihenfolge, die Sie nicht interessieren. Verantwortlich: Engineering.

​

2. Live-API-Schlüssel

Bringen Sie den Produktionsverkehr mit einem Rotations- und Zugriffsplan auf Live-Schlüssel.

• KYC ist freigegeben und das Guthaben ist aufgeladen. Diese beiden Punkte schalten den Live-Versand frei; beide sind für SMS, WhatsApp und Sprache erforderlich. Verantwortlich: Betrieb.
• Ein Live-Geheimschlüssel (dv_live_sk_) wurde unter Einstellungen → API-Schlüssel für jeden sendenden Dienst erstellt. Lagern Sie ihn in einem Secrets-Manager; niemals im Repository oder in clientseitigem Code. Ein kompromittierter Schlüssel wird widerrufen und neu erstellt. Verantwortlich: Engineering.
• Eine IP-Allowlist ist für Live-Schlüssel konfiguriert. Beschränken Sie, welche Quell-IPs Ihre Live-Zugangsdaten nutzen dürfen – siehe IP-Allowlist für API-Schlüssel. Verantwortlich: Engineering.

​

3. Rufnummern- und Absenderbereitschaft

Stellen Sie sicher, dass die Absenderidentität, die Sie nutzen, tatsächlich live-fähig ist.

• Ihre Messaging-Nummern sind SMS-fähig. Wenn Sie WhatsApp nutzen, ist der an ein WhatsApp-Business-Profil (WABA) gebundene Absender bereit. Verantwortlich: Betrieb.
• 10DLC-Marke und -Kampagne sind für US-A2P-SMS registriert. Vor US-SMS-Sendungen im Live-Verkehr erforderlich – siehe 10DLC-Registrierung. Ergänzend zu KYC, kein Ersatz dafür. Verantwortlich: Compliance/Betrieb.
• TFV (Toll-Free Verification) und/oder CNAM sind, wo relevant, eingerichtet. CNAM betrifft die Anrufer-ID-Anzeige bei Sprache; TFV die Zustellbarkeit von Toll-Free-SMS. Verantwortlich: Compliance/Betrieb.

​

4. Webhooks

Live-Verkehr braucht einen Produktions-Webhook-Endpunkt, nicht nur einen Test-Tunnel.

• Der Endpunkt wird über HTTPS mit einem gültigen Zertifikat ausgeliefert. Nur-HTTP-Endpunkte werden abgelehnt. Verantwortlich: Engineering.
• Die Signaturprüfung ist eingerichtet. Prüfen Sie X-Orbit-Signature (mit Fallback auf die ältere X-Devotel-Signature) gegen Ihr Signaturgeheimnis; lehnen Sie fehlende oder abweichende Signaturen ab – siehe Webhook-Sicherheit. Verantwortlich: Engineering.
• Der Replay-Schutz lehnt Zustellungen mit Zeitstempeln älter als fünf Minuten ab. Der t=-Wert steckt im selben Signatur-Header. Verantwortlich: Engineering.
• Ihre eingehende Firewall lässt die von Orbit veröffentlichten Webhook-Egress-IPs durch. Rufen Sie die aktuelle Liste von GET /api/v1/webhooks/egress-ips ab und tragen Sie sie in Ihrem Empfänger ein. Verantwortlich: Engineering.

​

5. Versand-Leitplanken

Entscheiden Sie, wie Ihr Verkehr Fehlern widersteht, bevor eine Kampagne herausgeht.

• Opt-out-Listen sind konfiguriert. STOP und verwandte Schlüsselwörter fließen in eine Liste, die Ihr Versandpfad prüft. Verantwortlich: Betrieb.
• Frequency-Caps passen zu Ihrem Anwendungsfall. Marketing-Verkehr erhält empfängerseitige Obergrenzen; Systemverkehr erhält kohärente Limits. Verantwortlich: Betrieb.
• Nachrichten-Unterdrückung deckt die benötigten Bereiche ab. Harte Sperren bleiben kanalübergreifend bestehen. Verantwortlich: Betrieb.
• DNC- und verwandte Versand-Gates sind verankert, wo erforderlich. Ruhezeiten, DNC-Scrub und Notfall-Stopp liegen unter Compliance → Send Gates. Verantwortlich: Compliance.

​

6. Wallets und Abrechnung

Live-Verkehr belastet ein echtes Guthaben; vermeiden Sie überraschende Stillstände.

• Die Wallet hat genügend Guthaben für das Launch-Volumen plus Puffer. Verantwortlich: Betrieb/Finanzen.
• Pro-Funktion-Budgets begrenzen die Kampagnen und Agenten, die Sie betreiben. Verantwortlich: Betrieb/Finanzen.
• Warnungen zu niedrigem Guthaben und Ausgaben erreichen den Bereitschaftsverantwortlichen. Verantwortlich: Betrieb/Finanzen.

​

7. Compliance-Bereitschaft

Compliance-Gates unterscheiden sich je nach Land und Kanal; klären Sie sie vor dem Launch vorab.

• Eine Notrufadresse ist für Sprachrufnummern hinterlegt, wo die jeweilige Jurisdiktion sie verlangt. Siehe Notruf. Verantwortlich: Compliance.
• Länderspezifische Anforderungen sind für jedes Zielland dokumentiert. Länderspezifische Anforderungen listen die Regeln je Land. Verantwortlich: Compliance.
• Ihre 10DLC-Marken- und Kampagnenstatus sind freigegeben. Nicht nur eingereicht. Verantwortlich: Compliance.
• DNC-Scrub und Opt-out-Behandlung sind aktiv und bleiben aktiv. Ruhezeiten und Register-Scans liegen unter Send Gates. Verantwortlich: Compliance.

​

8. Launch-Tag-Ablaufplan

Eine kurze Sequenz, der Teams typischerweise folgen:

1. T-24 Std. – Freigabe. Ein Verantwortlicher zieht jede Checkbox durch; Engineering friert Absender, Schlüssel und Webhooks ein.
2. T-1 Std. – letzte Prüfung. KYC-Freigabe, Wallet-Guthaben, lebender Webhook-Endpunkt und 10DLC-Freigabe erneut bestätigen.
3. T-0 – Canary. Einen kleinen Live-Batch senden und die Zustellereignisse im Canary-Fenster beobachten.
4. T+1 Std. – ausweiten. Bleiben die Fehler innerhalb der Alarm-Schwelle, auf die volle Zielgruppe erweitern.
5. Nach dem Launch – weiter beobachten. Fehlerrate, Wallet-Guthaben und Alarm-Posteingänge bleiben am ersten Tag überwacht.