Pourquoi ma vérification toll-free SMS a-t-elle été rejetée ?

Après qu'un opérateur a rejeté un dossier, la vérification expose son motif séparément des statuts des éléments. denial_reasons contient l'explication de l'opérateur. La liste des exigences enregistre ce que vous avez fourni, pas quelle réponse a causé le rejet.

Le premier endroit où l'on regarde est la liste des exigences, et elle ne peut pas répondre à cette question. Comprendre pourquoi fait gagner beaucoup de temps.

Où se trouve le motif du rejet ?

Utilisez bird sms tfn verifications get pour lire la vérification. La commande renvoie l'état, l'expéditeur qu'elle autorise et la réponse de l'opérateur. denial_reasons contient cette réponse sous forme de texte.

Un détail à anticiper : les motifs accompagnent un rejet. Quand un opérateur demande des modifications au lieu de refuser directement, la vérification passe à info_requested et enregistre le nouveau statut sans motifs joints. Une vérification qui vous demande plus d'informations ne vous dira donc pas lesquelles, et c'est la liste des exigences qu'il faut consulter à ce moment-là pour voir quels éléments manquent encore.

Pourquoi la liste des exigences ne peut-elle pas indiquer quelle réponse était incorrecte ?

Parce que l'opérateur ne statue pas réponse par réponse. Il statue sur le dossier dans son ensemble, et Bird projette ce verdict unique sur chaque élément que vous avez fourni.

Sur une vérification rejetée, chaque élément fourni affiche rejected, qu'il ait causé le problème ou non. Chaque élément vide affiche not_supplied. Rien dans la liste n'est plus rejeté qu'un autre élément. La liste ne vous donne aucun coupable, utilisez donc denial_reasons.

La véritable utilité de la liste des exigences est la structure du dossier : ce qui est demandé, ce que vous avez répondu et ce qui manque encore.

Que demande réellement l'opérateur ?

Demandez les exigences sans nommer de vérification et vous obtenez le formulaire vierge : chaque élément demandé par les opérateurs, dans l'ordre de présentation. Nommez-en une avec --verification-id et vous obtenez la même liste portant ses propres réponses.

Chaque élément est accompagné d'un key sous lequel le soumettre, d'un label à présenter à la personne qui doit y répondre, d'un help_text décrivant à quoi ressemble une bonne réponse, et d'une indication précisant si une réponse est required. Les éléments optionnels sont tout de même examinés quand vous les fournissez.

Deux réponses sont des ensembles fermés à connaître avant de commencer :

• Structure juridique, parmi sole_proprietor, private_profit, public_profit, non_profit ou government. L'orthographe est la même que les cinq structures 10DLC, et il s'agit volontairement d'une liste distincte, car chaque autorité décide elle-même de ce qu'elle accepte.
• Volume mensuel, sous forme de tranche plutôt que de nombre : onze tranches, de up_to_10 à up_to_1m puis up_to_5m, jusqu'à above_5m.

Chaque élément signale aussi un state, et une lecture toll-free en renvoie cinq : not_supplied, supplied, in_review, approved et rejected. Considérez l'ensemble comme ouvert, car l'examen peut acquérir des étapes.

Comment savoir si c'est en attente de ma part ou de celle de l'opérateur ?

Deux booléens sur la lecture des exigences y répondent, et un seul d'entre eux vous concerne.

satisfied n'est vrai qu'une fois la vérification approuvée. Une demande complète peut encore être en attente d'approbation.

needs_input est vrai quand c'est à vous de jouer. Cela couvre quatre situations : un élément requis n'a pas de réponse, l'opérateur a demandé des modifications, votre brouillon est complet mais personne ne l'a soumis, ou un rejet est encore dans sa fenêtre de resoumission.

Les deux à faux est la combinaison à reconnaître, car elle a deux significations. Soit l'opérateur détient le dossier et il n'y a rien à faire qu'attendre, soit votre vérification a été rejetée et sa fenêtre de resoumission est déjà fermée. resubmit_allowed est ce qui distingue ces deux cas, ce qui est une bonne raison de le lire chaque fois que vous lisez un rejet.

Que signifient les six états de vérification ?

Puis-je corriger une vérification rejetée ?

Parfois, et un seul champ y répond : une vérification rejetée ne peut être corrigée et resoumise que tant que resubmit_allowed est vrai. Utilisez le drapeau renvoyé et l'état d'examen avant de modifier ou de resoumettre, plutôt que de calculer l'éligibilité à partir d'une date seule.

Une vérification est modifiable tant qu'elle est en brouillon, quand l'opérateur a demandé plus d'informations, et tant qu'un rejet est encore dans sa fenêtre de resoumission. Tout le reste est verrouillé, y compris submitted et under_review ainsi que approved, donc les deux états dans lesquels vous passez le plus de temps à attendre sont aussi des états depuis lesquels vous ne pouvez pas modifier. Toute tentative renvoie un conflit.

Corriger une réponse ne signifie pas ressaisir les autres. Une mise à jour n'applique que les champs que vous envoyez, donc une seule mauvaise réponse ne vous coûte que cette réponse, pas le dossier.

Quelles commandes utiliser ?

Six commandes couvrent le cycle de vie, et une étape en est absente volontairement.

bird sms tfn verifications requirements lit la vue élément par élément, et get, create, update, list et cancel font ce que leurs noms indiquent. Soumettre une vérification pour examen n'en fait pas partie : cela se passe dans le tableau de bord.

Un raccourci vaut la peine d'être connu pendant que vous remplissez le formulaire. Passer --identity-id préremplit les exigences commerciales et de contact à partir d'une partie que vous avez déjà décrite, et celles-ci reviennent marquées comme préremplies. Les exigences de messagerie et de consentement ne sont jamais préremplies, car vous les rédigez à neuf pour chaque vérification, et tout ce que vous avez déjà soumis pour cette vérification l'emporte sur la réponse de la partie.

Il n'existe pas non plus d'événement webhook public pour l'état de vérification toll-free, donc un abonnement ne peut pas vous informer quand une décision arrive. Interroger la commande get est le moyen de le savoir.