Eine bestehende Messaging-Kampagne deaktivieren
Verwenden Sie diese Route, wenn eine kontoeigene Kampagne außer Betrieb genommen wird. Bewahren Sie ihre Kampagnen-ID für den Abgleich und die Historie auf. Für inhaltliche Korrekturen oder Aktualisierungen des Einwilligungstexts verwenden Sie die Funktion Eine Messaging-Kampagne aktualisieren statt dieser Route.
Authentifizieren Sie sich mit einem aktivierten API-Konto über HTTPS von einer zulässigen Quell-IP-Adresse aus. Rufen Sie zunächst die Kampagne ab und prüfen Sie die zugehörige Marke sowie die Absendernummern. Die Deaktivierung ändert die Registrierung; sie erstellt weder eine Ersatzkampagne noch verschiebt sie Rufnummern zu einer anderen Kampagne.
curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
"https://api.multitel.net/tcr/v2/campaign/$CAMPAIGN_ID"Zuerst die betroffenen Rufnummernzuordnungen entfernen
Die öffentliche DELETE-Operation für Kampagnen trennt Rufnummern weder vom Messaging-Netzbetreiber noch entfernt sie deren lokale Zuordnung. Verwenden Sie den Ablauf zum Entfernen einer Rufnummernzuordnung zu einer Kampagne für jede betroffene kontoeigene Rufnummer und überprüfen Sie anschließend deren Zuordnung. Das Entfernen einer Zuordnung gibt die Rufnummer nicht frei.
Der umfassendere Portal-Ablauf „Marke löschen“ bereinigt zunächst die Kampagnen und Rufnummern der Marke, bevor er die Marke löscht. Verwenden Sie diese Aktion nicht, wenn Sie die Marke und ihre anderen Kampagnen behalten möchten. Der derzeitige reguläre Kampagneneditor bietet keine separate Schaltfläche zum Löschen einer Kampagne, die dieser direkten API-Route entspricht.
Die vorgesehene Deaktivierung anfordern
Nachdem Sie die Kampagnen-ID und die betroffene Versandkonfiguration geprüft haben, senden Sie DELETE ohne JSON-Anfragetext:
curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
--request DELETE \
--header "Idempotency-Key: $IDEMPOTENCY_KEY" \
"https://api.multitel.net/tcr/v2/campaign/$CAMPAIGN_ID"Die dokumentierte Erfolgsantwort ist HTTP 204 mit leerem Antworttext. Prüfen Sie den HTTP-Status, statt eine JSON-Antwortstruktur mit status/response zu erwarten. Bei akzeptierter Löschung kennzeichnet der aktuelle Dienst die Kampagnenressource lokal als gelöscht und abgelaufen sowie den zugehörigen älteren Kampagnendatensatz als abgelaufen. Die Löschung wird nicht auf die Marke ausgeweitet.
Verwenden Sie für diese beabsichtigte Anfrage einen einzigen Idempotenzschlüssel und bewahren Sie Methode, Pfad, Abfrage und die Bytes des Anfragetexts für eine Wiederholung exakt auf. Eine doppelte Anfrage, deren Verarbeitung noch läuft, kann 409 mit Retry-After zurückgeben; bei abgeschlossenen Anfragen kann das gespeicherte Ergebnis erneut ausgegeben werden. Ein zwischengespeicherter Fehler oder eine unterbrochene Verbindung lässt nicht erkennen, ob die Registrierungsstelle bereits gehandelt hat. Bewahren Sie die Kampagnen-ID und, sofern vorhanden, requestId auf.
Sowohl Registrierung als auch Zuordnungen überprüfen
Prüfen Sie nach der Anfrage den aktuellen Zustand der Kampagne und die betroffenen Rufnummern im Portal. Die API kann lokale Metadaten zur Kontozugehörigkeit nach der Außerbetriebnahme beibehalten, sodass eine zum Konto gehörende Kennung weiterhin geprüft werden kann; schließen Sie daraus nicht, dass dieselbe ID lokal immer 404 zurückgeben muss. Die Registrierungsstelle bestimmt den zurückgegebenen Status beziehungsweise die Verfügbarkeit des außer Betrieb genommenen Datensatzes.
Wenn eine Rufnummer weiterhin zugeordnet ist, gleichen Sie diese bestehende Zuordnung ab. Erstellen Sie keine weitere Kampagne, nur um die Deaktivierung erneut zu versuchen, und nehmen Sie nicht an, dass HTTP 204 die erfolgte Bereinigung beim Netzbetreiber belegt. Wenn die lokale Synchronisierung fehlschlägt, nachdem die Registrierungsstelle die Anfrage akzeptiert hat, kann die API 500 zurückgeben, obwohl die externe Deaktivierung bereits erfolgt ist.
| Ergebnis | Nächster Schritt |
|---|---|
| 204 | Ein Antworttext wird nicht erwartet. Überprüfen Sie den Kampagnenzustand und die unabhängig davon verwalteten Rufnummernzuordnungen. |
| 400 | Lesen Sie die zurückgegebene Fehlermeldung zur Validierung oder zum Zustand bei der Registrierungsstelle. Prüfen Sie die genaue Kampagnen-ID und den bestehenden Zustand. |
| 401, 403, 404 | Prüfen Sie die API-Zugangsdaten, die zulässige Quell-IP-Adresse und die Kontozugehörigkeit. Verwenden Sie nicht ersatzweise die ID eines anderen Kunden. |
| 409, 429 | Unterscheiden Sie eine noch laufende oder in Konflikt stehende idempotente Anfrage von einer Begrenzung der Anfragerate; beachten Sie Retry-After, sofern angegeben. |
| 500, 502 oder Zeitüberschreitung | Bewahren Sie die Anfragedetails auf, rufen Sie die bestehende Kampagne ab und gleichen Sie den Zustand vor einer erneuten Anfrage ab. |
Außerbetriebnahme und Kontoabrechnung sind getrennte Vorgänge
Der aktuelle DELETE-Dienst veranlasst keine sofortige Belastung für die Kampagnenregistrierung. Dies stellt weder eine Rückerstattung in Aussicht noch hebt es eine bestehende Verpflichtung auf oder gibt gemietete Rufnummern frei. Prüfen Sie die Kampagnenbedingungen des Kontos und offene Rechnungen im Portal. Rufnummernmiete und Nachrichtennutzung werden getrennt von der Kampagnenregistrierung behandelt.
Wenn die gesamte Unternehmensregistrierung außer Betrieb genommen werden soll, nachdem ihre Kampagnen und Zuordnungen abgeglichen wurden, fahren Sie mit folgendem Vorgang fort: Außerbetriebnahme der Marke.