SMS

Waarom is mijn toll-free SMS-verificatie afgewezen?

Een toll-free-verificatie is een dossier dat een carrier beoordeelt, en de status vertelt je dat de carrier nee heeft gezegd zonder te vertellen waar het bezwaar tegen was.

Nadat een carrier een dossier afwijst, toont de verificatie de reden los van de itemstatussen. denial_reasons bevat de uitleg van de carrier. De lijst met vereisten registreert wat je hebt aangeleverd, niet welk antwoord de afwijzing veroorzaakte.

De plek waar mensen als eerste kijken is de lijst met vereisten, en die kan dit niet beantwoorden. Begrijpen waarom scheelt veel tijd.

Waar staat de reden voor de afwijzing?

Gebruik bird sms tfn verifications get om de verificatie te lezen. Het retourneert de status, de afzender die het licentieert en het antwoord van de carrier. denial_reasons bevat dat antwoord als tekst.

Eén detail om rekening mee te houden: redenen komen alleen bij een afwijzing. Wanneer een carrier om wijzigingen vraagt in plaats van ronduit af te wijzen, gaat de verificatie naar info_requested en wordt de nieuwe status vastgelegd zonder redenen. Een verificatie die je om meer informatie vraagt, vertelt dus niet wát, en de lijst met vereisten is dan de plek om te kijken welke items nog ontbreken.

Waarom kan de lijst met vereisten niet zeggen welk antwoord fout was?

Omdat de carrier niet antwoord voor antwoord beslist. De carrier beoordeelt het dossier als geheel, en Bird projecteert dat ene oordeel op elk item dat je hebt aangeleverd.

Bij een afgewezen verificatie heeft elk ingevuld item de status rejected, of het nu het probleem veroorzaakte of niet. Elk leeg item heeft de status not_supplied. Niets in de lijst is meer afgewezen dan een ander item. De lijst geeft je geen schuldige, dus gebruik denial_reasons.

Waar de lijst met vereisten werkelijk voor dient is de vorm van het dossier: wat er gevraagd wordt, wat je hebt beantwoord en wat nog ontbreekt.

Wat vraagt de carrier precies?

Vraag de vereisten op zonder een verificatie te noemen en je krijgt het lege formulier: elk item dat de carriers vragen, in de volgorde om het te presenteren. Noem er een met --verification-id en je krijgt dezelfde lijst met de bijbehorende antwoorden.

Elk item heeft een key om het onder in te dienen, een label om voor te leggen aan degene die het moet beantwoorden, help_text die beschrijft hoe een goed antwoord eruitziet, en of een antwoord required is. Optionele items worden alsnog beoordeeld als je ze aanlevert.

Twee antwoorden zijn gesloten sets die de moeite waard zijn om vooraf te kennen:

  • Juridische structuur, een van sole_proprietor, private_profit, public_profit, non_profit of government. Deze zijn hetzelfde gespeld als de vijf structuren van 10DLC en vormen bewust een aparte lijst, omdat elke autoriteit zelf bepaalt wat ze accepteert.
  • Maandelijks volume, als een band in plaats van een getal: elf stuks, van up_to_10 via up_to_1m en up_to_5m, eindigend op above_5m.

Elk item rapporteert ook een state, en een toll-free-leesactie geeft er vijf terug: not_supplied, supplied, in_review, approved en rejected. Beschouw de set als open, aangezien de beoordeling stappen kan bijkrijgen.

Hoe zie ik of het op mij wacht of op de carrier?

Twee booleans op de requirements-leesactie beantwoorden dat, en maar één ervan gaat over jou.

satisfied is pas true zodra de verificatie is goedgekeurd. Een volledige aanvraag kan nog op goedkeuring wachten.

needs_input is true wanneer jij aan zet bent. Dat dekt vier situaties: een verplicht item heeft geen antwoord, de carrier heeft om wijzigingen gevraagd, je concept is compleet maar niemand heeft het ingediend, of een afwijzing zit nog binnen het herinzendingsvenster.

Beide false is de combinatie die je moet herkennen, want die heeft twee betekenissen. Of de carrier houdt het dossier vast en je kunt alleen wachten, of je verificatie is afgewezen en het herinzendingsvenster is al gesloten. resubmit_allowed onderscheidt die twee, wat een goede reden is om het altijd te lezen wanneer je een afwijzing leest.

Wat betekenen de zes verificatiestatussen?

StatusWat het betekent
draftJe kunt de bedrijfs- en berichtgegevens bewerken of indienen
submittedDe verificatie is naar de carrier gestuurd voor beoordeling
under_reviewDe carrier beoordeelt het
info_requestedDe carrier wil wijzigingen voordat het beslist, en je kunt bewerken en opnieuw indienen
approvedHet nummer is goedgekeurd voor het ingediende programma in de toegestane landen onder SMS-bestemmingen. De goedkeuring betreft het ingediende programma; elke verzending vereist nog steeds toestemming van de ontvanger en een toegestane bestemming
rejectedDe carrier heeft het afgewezen

Kan ik een afgewezen verificatie herstellen?

Soms, en één veld beantwoordt het: een afgewezen verificatie kan alleen gecorrigeerd en opnieuw ingediend worden zolang resubmit_allowed true is. Gebruik de geretourneerde vlag en beoordelingsstatus voordat je bewerkt of opnieuw indient, in plaats van geschiktheid alleen uit een datum af te leiden.

Een verificatie is bewerkbaar zolang het een concept is, wanneer de carrier om meer informatie heeft gevraagd, en zolang een afwijzing nog binnen het herinzendingsvenster zit. Al het andere is vergrendeld, inclusief submitted en under_review naast approved, dus de twee statussen waar je het langst op wacht zijn beide statussen van waaruit je niet kunt bewerken. Toch proberen levert een conflict op.

Eén antwoord corrigeren betekent niet dat je de rest opnieuw moet invoeren. Een update past alleen de velden toe die je meestuurt, dus één fout antwoord kost je dat antwoord in plaats van het hele dossier.

Welke commando's gebruik ik?

Zes commando's dekken de levenscyclus, en één stap ontbreekt met opzet.

bird sms tfn verifications requirements leest de item-voor-itemweergave, en get, create, update, list en cancel doen wat hun naam zegt. Indienen voor beoordeling zit er niet bij: dat gebeurt in het dashboard.

Eén snelkoppeling is handig terwijl je het formulier invult. Door --identity-id mee te geven vul je de bedrijfs- en contactvereisten vooraf in vanuit een partij die je al hebt beschreven, en die komen terug gemarkeerd als vooraf ingevuld. De bericht- en opt-in-vereisten worden nooit vooraf ingevuld, omdat je die voor elke verificatie opnieuw schrijft, en alles wat je al voor deze verificatie hebt ingediend gaat boven het antwoord van de partij.

Er is ook geen publiek webhook-event voor de status van een toll-free-verificatie, dus een abonnement kan je niet vertellen wanneer een beslissing binnenkomt. Polling van het get-commando is de manier om erachter te komen.

Kort gezegd

  1. De reden staat op de verificatie, in denial_reasons.

    Lees die met het get-commando. Het veld is alleen gevuld bij een afwijzing, niet wanneer de carrier alleen om meer informatie vraagt.

  2. De lijst met vereisten kan het foute antwoord niet aanwijzen.

    Een carrier beoordeelt het dossier als geheel, dus bij een afwijzing heeft elk ingevuld item de status rejected. De itemstatussen vertellen je wat aanwezig is, niet wat fout was.

  3. Twee booleans geven aan wie aan zet is.

    needs_input is true wanneer jij aan zet bent. Beide false betekent dat de carrier het dossier heeft, of dat je herinzendingsvenster gesloten is.

  4. Een afgewezen verificatie is alleen bewerkbaar zolang resubmit_allowed true is.

    Een afgewezen verificatie kan alleen gecorrigeerd worden zolang resubmit_allowed true is, en die vlag blijft bestaan na het venster waarmee hij is toegekend.

Breng het in de praktijk.

Ga verder met de documentatie, gidsen en voorbeelden voor dit onderwerp. De bronnen zijn in het Engels.

Probeer de oefening en ontvang een implementatieoverzicht

Bouw op hetzelfde netwerk.

Een test-API-key is direct beschikbaar. Productietoegang wordt ontgrendeld zodra u een betaalmethode toevoegt en een afzender verifieert.

Jouw volgende idee.
Klaar om te verbinden.