Nachdem ein Carrier ein Dossier abgelehnt hat, zeigt die Verifizierung den Grund getrennt von den Eintragsstatus an. denial_reasons enthält die Erklärung des Carriers. Die Anforderungsliste dokumentiert, was Sie geliefert haben, nicht welche Antwort die Ablehnung verursacht hat.
Der erste Blick fällt meist auf die Anforderungsliste, und sie kann diese Frage nicht beantworten. Zu verstehen, warum, spart viel Zeit.
Wo steht der Grund für die Ablehnung?
Verwenden Sie bird sms tfn verifications get, um die Verifizierung auszulesen. Der Befehl gibt den Status, den lizenzierten Absender und die Antwort des Carriers zurück. denial_reasons enthält diese Antwort als Text.
Ein Detail, auf das Sie sich einstellen sollten: Gründe kommen nur bei einer Ablehnung. Wenn ein Carrier statt einer direkten Ablehnung Änderungen anfordert, wechselt die Verifizierung zu info_requested und speichert den neuen Status ohne beigefügte Gründe. Eine Verifizierung, die weitere Informationen von Ihnen anfordert, sagt Ihnen also nicht welche. In dem Fall schauen Sie in die Anforderungsliste, um zu sehen, welche Einträge noch fehlen.
Warum kann die Anforderungsliste nicht sagen, welche Antwort falsch war?
Weil der Carrier nicht Antwort für Antwort entscheidet. Er entscheidet über das Dossier als Ganzes, und Bird projiziert dieses einzelne Urteil auf jeden gelieferten Eintrag.
Bei einer abgelehnten Verifizierung steht bei jedem gelieferten Eintrag rejected, unabhängig davon, ob er das Problem verursacht hat. Bei jedem leeren Eintrag steht not_supplied. Kein Eintrag in der Liste ist stärker abgelehnt als ein anderer. Die Liste liefert Ihnen keinen Verursacher, verwenden Sie also denial_reasons.
Die Anforderungsliste dient tatsächlich der Struktur des Dossiers: was gefragt ist, was Sie beantwortet haben und was noch fehlt.
Was fordert der Carrier tatsächlich an?
Fragen Sie die Anforderungen ohne Angabe einer Verifizierung ab und Sie erhalten das leere Formular: jeden Eintrag, den die Carrier verlangen, in der vorgesehenen Reihenfolge. Geben Sie eine mit --verification-id an und Sie erhalten dieselbe Liste mit den eigenen Antworten.
Jeder Eintrag enthält einen key zur Einreichung, einen label zur Vorlage bei der Person, die ihn beantworten muss, help_text mit einer Beschreibung einer guten Antwort, und ob eine Antwort required ist. Optionale Einträge werden trotzdem geprüft, wenn Sie sie liefern.
Zwei Antworten sind geschlossene Mengen, die Sie vorab kennen sollten:
- Rechtsform, eine von
sole_proprietor,private_profit,public_profit,non_profitodergovernment. Sie sind identisch geschrieben wie die fünf Strukturen von 10DLC und bilden bewusst eine separate Liste, weil jede Stelle selbst entscheidet, was sie akzeptiert. - Monatliches Volumen, als Bereich statt als Zahl: elf Stufen, von
up_to_10überup_to_1mundup_to_5mbisabove_5m.
Jeder Eintrag meldet außerdem einen state, und ein Toll-Free-Read gibt fünf davon aus: not_supplied, supplied, in_review, approved und rejected. Behandeln Sie die Menge als offen, da die Prüfung weitere Stufen erhalten kann.
Wie erkenne ich, ob es auf mich oder auf den Carrier wartet?
Zwei Booleans auf der Anforderungsabfrage beantworten das, und nur einer davon betrifft Sie.
satisfied ist erst true, wenn die Verifizierung genehmigt ist. Ein vollständiger Antrag kann weiterhin auf Genehmigung warten.
needs_input ist true, wenn Sie am Zug sind. Das umfasst vier Situationen: ein Pflichtfeld hat keine Antwort, der Carrier hat Änderungen angefordert, Ihr Entwurf ist vollständig aber niemand hat ihn eingereicht, oder eine Ablehnung liegt noch innerhalb des Zeitfensters zur erneuten Einreichung.
Beide false ist die Kombination, die Sie erkennen sollten, weil sie zwei Bedeutungen hat. Entweder hält der Carrier das Dossier und es bleibt nur zu warten, oder Ihre Verifizierung wurde abgelehnt und das Zeitfenster zur erneuten Einreichung ist bereits geschlossen. resubmit_allowed unterscheidet die beiden Fälle, weshalb Sie es bei jeder Ablehnung mitlesen sollten.
Was bedeuten die sechs Verifizierungsstatus?
| Status | Bedeutung |
|---|---|
draft | Sie können die Geschäfts- und Nachrichtendetails bearbeiten oder einreichen |
submitted | Die Verifizierung wurde zur Prüfung an den Carrier gesendet |
under_review | Der Carrier prüft sie |
info_requested | Der Carrier verlangt Änderungen vor der Entscheidung, und Sie können bearbeiten und erneut einreichen |
approved | Die Nummer ist für das eingereichte Programm in den unter SMS-Ziele aufgeführten zulässigen Ländern freigegeben. Die Freigabe gilt für das eingereichte Programm; jeder Versand erfordert weiterhin die Zustimmung des Empfängers und ein zulässiges Ziel |
rejected | Der Carrier hat sie abgelehnt |
Kann ich eine abgelehnte Verifizierung korrigieren?
Manchmal, und ein Feld beantwortet das: Eine abgelehnte Verifizierung kann nur korrigiert und erneut eingereicht werden, solange resubmit_allowed true ist. Verwenden Sie das zurückgegebene Flag und den Prüfstatus vor dem Bearbeiten oder erneuten Einreichen, statt die Berechtigung allein aus einem Datum zu berechnen.
Eine Verifizierung ist bearbeitbar, solange sie ein Entwurf ist, wenn der Carrier weitere Informationen angefordert hat, und solange eine Ablehnung noch innerhalb des Zeitfensters zur erneuten Einreichung liegt. Alles andere ist gesperrt, darunter submitted und under_review ebenso wie approved. Die beiden Status, in denen Sie am längsten warten, sind also beide nicht bearbeitbar. Ein Versuch gibt trotzdem einen Konflikt zurück.
Eine einzelne Antwort zu korrigieren bedeutet nicht, alle anderen erneut einzugeben. Ein Update wendet nur die Felder an, die Sie senden. Eine einzelne fehlerhafte Antwort kostet Sie also nur diese Antwort, nicht das gesamte Dossier.
Welche Befehle verwende ich?
Sechs Befehle decken den Lebenszyklus ab, und ein Schritt fehlt darin absichtlich.
bird sms tfn verifications requirements liest die Eintrag-für-Eintrag-Ansicht, und get, create, update, list und cancel tun, was ihre Namen sagen. Die Einreichung einer Verifizierung zur Prüfung ist nicht darunter: Sie erfolgt im Dashboard.
Eine Abkürzung ist nützlich, während Sie das Formular ausfüllen. Durch Übergabe von --identity-id werden die Geschäfts- und Kontaktanforderungen aus einer bereits beschriebenen Partei vorausgefüllt, und diese kommen als vorausgefüllt markiert zurück. Die Nachrichten- und Opt-in-Anforderungen werden nie vorausgefüllt, weil Sie diese für jede Verifizierung neu schreiben, und alles, was Sie für diese Verifizierung bereits eingereicht haben, hat Vorrang vor der Antwort der Partei.
Es gibt auch kein öffentliches Webhook-Event für den Toll-Free-Verifizierungsstatus, daher kann ein Abonnement Sie nicht benachrichtigen, wenn eine Entscheidung eintrifft. Der Get-Befehl per Polling ist der Weg, es herauszufinden.
Kurz gesagt
Der Grund steht auf der Verifizierung, in
denial_reasons.Lesen Sie ihn mit dem Get-Befehl aus. Er wird bei einer Ablehnung befüllt, nicht wenn der Carrier lediglich weitere Informationen anfordert.
Die Anforderungsliste kann die fehlerhafte Antwort nicht identifizieren.
Ein Carrier entscheidet über das Dossier als Ganzes. Bei einer Ablehnung steht daher bei jedem gelieferten Eintrag
rejected. Die Eintragsstatus sagen Ihnen, was vorhanden ist, nicht was falsch war.Zwei Booleans zeigen an, wer am Zug ist.
needs_inputist true, wenn Sie am Zug sind. Beide false bedeutet, dass der Carrier das Dossier hält oder Ihr Zeitfenster zur erneuten Einreichung abgelaufen ist.Eine abgelehnte Verifizierung ist nur bearbeitbar, solange
resubmit_allowedtrue ist.Eine abgelehnte Verifizierung kann nur korrigiert werden, solange
resubmit_allowedtrue ist, und dieses Flag überdauert das Zeitfenster, mit dem es gewährt wurde.