Marke und Anwendungsfall zusammenhalten
Verwenden Sie die Marken-ID Ihres Kontos und einen Anwendungsfallwert, der von der Qualifizierungsliste derselben Marke zurückgegeben wurde. Der Kunden-Workflow prüft die Eigentümerschaft vor der Provider-Anfrage. Bestätigen Sie, dass der Wert usecase des zurückgegebenen Objekts mit dem ausgewählten Wert übereinstimmt. Eine Abfrage für eine Marke oder einen Anwendungsfall begründet keine Anforderungen für eine andere Marke oder einen anderen Anwendungsfall.
Die aktuellen Anforderungen lesen
| Feld | Wie das Portal es verwendet |
|---|---|
| minSubUsecases / maxSubUsecases | Minimale und maximale Anzahl an Unter-Anwendungsfällen für diese Auswahl. Wählen Sie Werte aus dem gültigen Katalog der Unter-Anwendungsfälle statt Freitext. |
| mnoMetadata | Carrier-spezifische Anforderungen, nach Carrier-ID gegliedert. Verwenden Sie für die Carrier-Auswahl IDs, die in der aktuellen Antwort vorhanden sind. |
| mnoSupport / qualify | Carrier-Unterstützung und Qualifizierung. Das Portal schließt Carrier aus, die in einem der beiden Felder ausdrücklich mit false markiert sind, und verlangt mindestens einen berechtigten ausgewählten Carrier. |
| minMsgSamples | Erforderliche Anzahl an Beispielen für einen Carrier. Das Portal verlangt mindestens ein nicht leeres Beispiel und erfüllt das höchste Minimum unter den berechtigten ausgewählten Carriern. |
| reqSubscriberOptin / reqSubscriberOptout / reqSubscriberHelp | Erforderliche Teilnehmererklärungen. Wo erforderlich, muss die entsprechende Erklärung true sein. Aktivierte Erklärungen benötigen außerdem ihre Felder für Schlüsselwörter und Antwortnachricht. |
| noEmbeddedLink / noEmbeddedPhone | Einschränkungen für eingebettete Links oder Telefonnummern. Das Portal lehnt ein deklariertes Merkmal ab, wenn ein berechtigter ausgewählter Carrier es verbietet. |
Die Anforderungen der ausgewählten Carrier gemeinsam anwenden
Carrier-Anforderungen können sich unterscheiden. Wird keine explizite Carrier-Liste übergeben, berücksichtigt das Portal alle Carrier-Metadaten in der Antwort; eine nicht leere Liste beschränkt die Prüfungen auf diese ausgewählten IDs. Verwenden Sie nicht nur die Beispielanzahl oder die Erklärungen des ersten Carriers. Wählen Sie Carrier aus der Antwort aus, prüfen Sie Unterstützung und Qualifizierung, erfüllen Sie das höchste anwendbare Beispielminimum und erfüllen Sie die erforderlichen Opt-in-, Opt-out- und Hilfe-Erklärungen über diese gesamte Auswahl hinweg. Das Portal lehnt ausgewählte Carrier-IDs ab, die in der aktuellen Antwort fehlen, und lehnt eine Auswahl ohne berechtigten Carrier ab.
Anforderungen beschreiben, was bereitgestellt werden muss; sie belegen nicht, dass der Einwilligungsprozess oder der Kampagneninhalt des Kunden diese Anforderungen erfüllt. Sammeln Sie wahrheitsgemäße, repräsentative Beispiele und Erklärungen. Aktivieren Sie Erklärungen nicht automatisch, damit ein Formular die Prüfung besteht.
Beispiele und Teilnehmerantworten vorbereiten
Das aktuelle Kampagnenformular verwendet sample1 bis sample5 für Nachrichtenbeispiele. Wenn die Anforderungen im verfügbaren Formular nicht erfüllt werden können, halten Sie an und klären Sie die Auswahl mit dem Support. Geben Sie für eine aktivierte Teilnehmererklärung die zugehörigen Schlüsselwörter und den Antworttext an: optinKeywords/optinMessage, optoutKeywords/optoutMessage und helpKeywords/helpMessage. Halten Sie die Beispiele konsistent mit dem gewählten Anwendungsfall und der tatsächlichen Kundenkommunikation.
Vor jeder Registrierungsanfrage prüfen
Aktualisieren Sie die Anforderungen, wenn sich die Marke, der Anwendungsfall oder die Carrier-Auswahl ändert. Das Portal validiert den ausgewählten Anwendungsfall, die Anzahl der Unter-Anwendungsfälle, die Carrier-Berechtigung, die Beispiele und die Erklärungen vor der Erstellung erneut. Prüfen Sie die Kontopreise und die Registrierungsbedingungen separat. Dieses GET registriert oder genehmigt keine Kampagne, teilt sie nicht mit dem Messaging-Carrier und weist keine Telefonnummer zu. Erstellung und Bereitstellung sind separate Vorgänge.
Eine fehlgeschlagene Anforderungsabfrage behandeln
Wenn die Anfrage fehlschlägt, unerwartetes JSON zurückgibt oder nicht mit dem ausgewählten Anwendungsfall übereinstimmt, lassen Sie das Formular unvollständig und lassen Sie den Kunden es erneut versuchen, nachdem der Fehler behoben ist. Ersetzen Sie nicht verfügbare Anforderungen nicht durch ein leeres Objekt und nehmen Sie nicht an, dass fehlende Daten keine Anforderungen bedeuten. Beachten Sie Retry-After und verwenden Sie Backoff bei Ratenbegrenzungen und Verfügbarkeitsfehlern.
Anfrage
Verwenden Sie ein aktiviertes API-Konto über HTTPS von einer zugelassenen Quell-IP-Adresse. Die aktuelle Route unterstützt die Konto-Authentifizierungsrichtlinie, einschließlich Basic-Authentifizierung und aktivierter Bearer-API-Konten. Verwenden Sie keine Provider-Anmeldedaten.
GET mit der Marken-ID und dem ausgewählten Anwendungsfallwert im URL-Pfad. Es ist kein Anfragetext erforderlich.
curl --fail-with-body --silent --show-error \
--user "$API_USER:$API_PASSWORD" \
"https://api.multitel.net/tcr/v2/campaignBuilder/brand/$BRAND_ID/usecase/$USECASE"| Name | Typ | Erforderlich | Beschreibung |
|---|---|---|---|
brand_id | string | Ja | Die Registry-Marken-ID, die Ihrem authentifizierten MultiTEL-Konto zugeordnet ist. Verwenden Sie die Marken-ID, nicht eine lokale Datenbankzeilen-ID, Kampagnen-ID oder Steuernummer des Unternehmens. Kodieren Sie sie als ein einzelnes URL-Pfadsegment. |
usecase | string | Ja | Der maschinenlesbare usecase-Wert, der aus der Qualifizierungsliste derselben Marke ausgewählt wurde. Behalten Sie seine Groß-/Kleinschreibung bei; senden Sie keine übersetzte Anzeigebezeichnung. Kodieren Sie ihn als ein einzelnes URL-Pfadsegment. |
Antwort
Die aktuelle TCR-Route gibt den JSON-Body der Registry direkt zurück und behält dessen HTTP-Status bei. Sie fügt nicht die veraltete v3-status/response-Hülle hinzu. Das gekürzte fiktive Beispiel ist kein Live-Qualifizierungsergebnis. Prüfen Sie den HTTP-Status und die erwartete JSON-Struktur, bevor Sie es verwenden. Das Portal erwartet ein Objekt, dessen usecase mit dem ausgewählten Anwendungsfall übereinstimmt. Carrier-Anforderungen befinden sich unter mnoMetadata, nach Carrier-ID gegliedert. Die Beispiel-Carrier-ID und die Anforderungen sind fiktiv. Weitere Provider-Felder können zurückgegeben werden.
Veranschaulichende Antwortstruktur; keine Live-Kontodaten und kein aktuelles Angebot.
{
"usecase": "2FA",
"minSubUsecases": 0,
"maxSubUsecases": 0,
"mnoMetadata": {
"12345": {
"mnoSupport": true,
"qualify": true,
"minMsgSamples": 1,
"reqSubscriberOptin": true,
"reqSubscriberOptout": true,
"reqSubscriberHelp": true,
"noEmbeddedLink": false,
"noEmbeddedPhone": false
}
}
}Fehler
- 401: Konto-Authentifizierung fehlgeschlagen. Prüfen Sie die API-Anmeldedaten, den Aktivierungsstatus und die geltenden Quell-IP-Einschränkungen.
- 404: Die Marke ist nicht dem authentifizierten Konto zugeordnet, oder der Provider kann die angeforderte Marke oder Auswahl nicht finden. Eine lokale Eigentümerschaftsverweigerung wird vor einer Provider-Anfrage zurückgegeben.
- Sonstige Registry-Fehler: Der vorgelagerte HTTP-Status und der Body werden beibehalten. Ein ungültiger oder nicht verfügbarer Anwendungsfall ist kein erfolgreicher leerer Anforderungssatz.
- 429: Anfragelimit des Kontos oder des gemeinsam genutzten Providers erreicht. Beachten Sie Retry-After.
- 502/503: Verfügbarkeitsfehler bei Transport, Provider oder Ratenbegrenzer. Behalten Sie das Formular bei und versuchen Sie es erneut mit Backoff.
Verfügbarkeit und Nebenwirkungen
- Das geprüfte GET prüft die bestehende Markeneigentümerschaft, kontaktiert die Registry und schreibt Anfrage-Audit-Datensätze. Es erstellt keine Marke oder Kampagne und berechnet keine Registrierungsgebühr.
- Provider-Gebührenmetadaten sind kein Endkundenangebot für MultiTEL-Kunden. Das Portal prüft die Kontopreise separat vor einer späteren Registrierungsanfrage.
- Qualifizierung und Anforderungen können sich ändern. Aktualisieren Sie sie für die ausgewählte Marke und den ausgewählten Anwendungsfall vor dem Einreichen. Eine erfolgreiche Abfrage ist keine Kampagnengenehmigung, keine Nummernzuweisung und keine Erlaubnis zum Beginn des Messagings.