Perché la mia verifica toll-free SMS è stata rifiutata?

Dopo che un carrier rifiuta un dossier, la verifica espone la motivazione separatamente dagli stati delle voci. denial_reasons contiene la spiegazione del carrier. La lista dei requisiti registra ciò che hai fornito, non quale risposta ha causato il rifiuto.

Il primo posto in cui si guarda è la lista dei requisiti, che però non può rispondere a questa domanda. Capire perché fa risparmiare molto tempo.

Dove si trova la motivazione del rifiuto?

Usa bird sms tfn verifications get per leggere la verifica. Restituisce lo stato, il sender che licenzia e la risposta del carrier. denial_reasons contiene quella risposta come testo.

Un dettaglio da tenere presente: le motivazioni accompagnano un rifiuto. Quando un carrier chiede modifiche invece di rifiutare del tutto, la verifica passa a info_requested e registra il nuovo stato senza motivazioni allegate. Quindi una verifica che ti chiede ulteriori informazioni non ti dirà quali, e la lista dei requisiti è dove guardare in quel caso, per vedere quali voci mancano ancora.

Perché la lista dei requisiti non può dire quale risposta era sbagliata?

Perché il carrier non decide risposta per risposta. Valuta il dossier nel suo insieme, e Bird proietta quel singolo verdetto su ogni voce che hai fornito.

In una verifica rifiutata, ogni voce fornita risulta rejected, che abbia o meno causato il problema. Ogni voce vuota risulta not_supplied. Nessun elemento nella lista è più rifiutato di un altro. La lista non ti dà il colpevole, quindi usa denial_reasons.

La lista dei requisiti serve davvero a descrivere la struttura del dossier: cosa è richiesto, cosa hai risposto e cosa manca ancora.

Cosa chiede effettivamente il carrier?

Richiedi i requisiti senza specificare una verifica e ottieni il modulo vuoto: ogni voce richiesta dai carrier, nell'ordine in cui presentarla. Specificane una con --verification-id e ottieni la stessa lista con le sue risposte.

Ogni voce include un key sotto cui inviarla, un label da mostrare a chi deve rispondere, help_text che descrive come deve essere una buona risposta, e se una risposta è required. Le voci opzionali vengono comunque esaminate quando le fornisci.

Due risposte sono insiemi chiusi che vale la pena conoscere prima di iniziare:

• Struttura legale, una tra sole_proprietor, private_profit, public_profit, non_profit o government. Sono scritte allo stesso modo delle cinque strutture di 10DLC e sono volutamente una lista separata, perché ogni autorità decide autonomamente cosa accettare.
• Volume mensile, come fascia anziché numero: undici fasce, da up_to_10 passando per up_to_1m e up_to_5m, fino a above_5m.

Ogni voce riporta anche un state, e una lettura toll-free ne emette cinque: not_supplied, supplied, in_review, approved e rejected. Considera l'insieme come aperto, perché la revisione può aggiungere fasi.

Come faccio a capire se è in attesa di me o del carrier?

Due booleani nella lettura dei requisiti rispondono, e solo uno dei due riguarda te.

satisfied è true solo quando la verifica è approvata. Un'applicazione completa può comunque essere in attesa di approvazione.

needs_input è true quando la prossima mossa è tua. Copre quattro situazioni: una voce obbligatoria non ha risposta, il carrier ha chiesto modifiche, la tua bozza è completa ma nessuno l'ha inviata, oppure un rifiuto è ancora dentro la sua finestra di reinvio.

Entrambi false è la combinazione da riconoscere, perché ha due significati. O il carrier ha in carico il dossier e non resta che attendere, oppure la tua verifica è stata rifiutata e la finestra di reinvio è già scaduta. resubmit_allowed è ciò che distingue i due casi, ed è un buon motivo per leggerlo ogni volta che leggi un rifiuto.

Cosa significano i sei stati della verifica?

Posso correggere una verifica rifiutata?

A volte, e un campo risponde: una verifica rifiutata può essere corretta e reinviata solo finché resubmit_allowed è true. Usa il flag restituito e lo stato di revisione prima di modificare o reinviare, anziché calcolare l'idoneità solo da una data.

Una verifica è modificabile finché è una bozza, quando il carrier ha chiesto ulteriori informazioni e finché un rifiuto è ancora dentro la sua finestra di reinvio. Tutto il resto è bloccato, inclusi submitted e under_review oltre a approved, quindi i due stati in cui passi più tempo ad attendere sono entrambi stati da cui non puoi modificare. Provare comunque restituisce un conflitto.

Correggere una risposta non significa reinserire le altre. Un aggiornamento applica solo i campi che invii, quindi una singola risposta errata ti costa quella risposta, non l'intero dossier.

Quali comandi uso?

Sei comandi coprono il ciclo di vita, e un passaggio manca volutamente.

bird sms tfn verifications requirements legge la vista voce per voce, e get, create, update, list e cancel fanno ciò che il loro nome indica. L'invio di una verifica per la revisione non è tra questi: avviene nella dashboard.

Una scorciatoia utile mentre compili il modulo. Passare --identity-id precompila i requisiti aziendali e di contatto da un soggetto che hai già descritto, e quelli tornano contrassegnati come precompilati. I requisiti di messaggistica e opt-in non vengono mai precompilati, perché li scrivi ex novo per ogni verifica, e qualsiasi cosa tu abbia già inserito per questa verifica prevale sulla risposta del soggetto.

Non esiste un evento webhook pubblico per lo stato della verifica toll-free, quindi una sottoscrizione non può dirti quando arriva una decisione. Il polling del comando get è il modo per scoprirlo.