Por que minha verificação toll-free SMS foi rejeitada?

Depois que a operadora rejeita um dossiê, a verificação expõe o motivo separadamente dos status dos itens. denial_reasons carrega a explicação da operadora. A lista de requisitos registra o que você forneceu, não qual resposta causou a rejeição.

O primeiro lugar onde as pessoas olham é a lista de requisitos, e ela não consegue responder a isso. Entender o porquê economiza muito tempo.

Onde está o motivo da rejeição?

Use bird sms tfn verifications get para ler a verificação. Ele retorna o estado, o remetente que ela licencia e a resposta da operadora. denial_reasons carrega essa resposta como texto.

Um detalhe para se preparar: os motivos vêm com uma rejeição. Quando a operadora pede alterações em vez de recusar diretamente, a verificação passa para info_requested e registra o novo status sem motivos anexados. Então uma verificação pedindo mais informações não vai dizer o quê, e a lista de requisitos é onde você olha nesse caso, para ver quais itens ainda estão faltando.

Por que a lista de requisitos não diz qual resposta estava errada?

Porque a operadora não decide resposta por resposta. Ela decide o dossiê como um todo, e Bird projeta esse veredito único sobre cada item que você forneceu.

Em uma verificação rejeitada, cada item fornecido aparece como rejected, tendo ou não causado o problema. Cada item em branco aparece como not_supplied. Nada na lista é mais rejeitado que outro item. A lista não aponta o culpado, então use denial_reasons.

O verdadeiro propósito da lista de requisitos é a estrutura do dossiê: o que é pedido, o que você já respondeu e o que ainda está faltando.

O que a operadora realmente pede?

Solicite os requisitos sem nomear uma verificação e você recebe o formulário em branco: cada item que as operadoras pedem, na ordem de apresentação. Nomeie uma com --verification-id e você recebe a mesma lista com suas próprias respostas.

Cada item vem com um key para enviar a resposta, um label para colocar na frente de quem precisa responder, help_text descrevendo como é uma boa resposta, e se a resposta é required. Itens opcionais ainda são analisados quando você os fornece.

Duas respostas são conjuntos fechados que vale a pena conhecer antes de começar:

• Estrutura jurídica, uma entre sole_proprietor, private_profit, public_profit, non_profit ou government. Elas têm a mesma grafia das cinco estruturas do 10DLC e são deliberadamente uma lista separada, porque cada autoridade decide por conta própria o que aceita.
• Volume mensal, como uma faixa em vez de um número: onze delas, de up_to_10 passando por up_to_1m e up_to_5m, até above_5m.

Cada item também reporta um state, e uma leitura toll-free emite cinco deles: not_supplied, supplied, in_review, approved e rejected. Trate o conjunto como aberto, já que a análise pode ganhar etapas.

Como saber se está esperando por mim ou pela operadora?

Dois booleanos na leitura de requisitos respondem a isso, e apenas um deles é sobre você.

satisfied só é true depois que a verificação é aprovada. Uma solicitação completa ainda pode estar aguardando aprovação.

needs_input é true quando a próxima ação é sua. Isso cobre quatro situações: um item obrigatório não tem resposta, a operadora pediu alterações, seu rascunho está completo mas ninguém o enviou, ou uma rejeição ainda está dentro da janela de reenvio.

Ambos false é a combinação que vale reconhecer, porque tem dois significados. Ou a operadora está com o dossiê e não há nada a fazer além de esperar, ou sua verificação foi rejeitada e a janela de reenvio já fechou. resubmit_allowed é o que separa esses dois casos, o que é um bom motivo para lê-lo sempre que você ler uma rejeição.

O que significam os seis estados de verificação?

Posso corrigir uma verificação rejeitada?

Às vezes, e um campo responde isso: uma verificação rejeitada só pode ser corrigida e reenviada enquanto resubmit_allowed for true. Use o flag retornado e o estado de análise antes de editar ou reenviar, em vez de calcular a elegibilidade apenas a partir de uma data.

Uma verificação é editável enquanto é rascunho, quando a operadora pediu mais informações, e enquanto uma rejeição ainda está dentro da janela de reenvio. Todo o resto é bloqueado, o que inclui submitted e under_review assim como approved, então os dois estados em que você mais espera são ambos estados dos quais não é possível editar. Tentar mesmo assim retorna um conflito.

Corrigir uma resposta não significa reentrar as outras. Uma atualização aplica apenas os campos que você envia, então uma única resposta errada custa apenas essa resposta, não o dossiê.

Quais comandos eu uso?

Seis comandos cobrem o ciclo de vida, e uma etapa está ausente deles de propósito.

bird sms tfn verifications requirements lê a visão item a item, e get, create, update, list e cancel fazem o que seus nomes dizem. Enviar uma verificação para análise não está entre eles: isso acontece no dashboard.

Um atalho que vale a pena conhecer enquanto você preenche o formulário. Passar --identity-id pré-preenche os requisitos de negócio e contato a partir de uma parte que você já descreveu, e eles voltam marcados como pré-preenchidos. Os requisitos de mensageria e opt-in nunca são pré-preenchidos, porque você os escreve do zero para cada verificação, e qualquer coisa que você já tenha registrado para esta verificação prevalece sobre a resposta da parte.

Também não existe evento de webhook público para o estado de verificação toll-free, então uma assinatura não pode avisar quando uma decisão chega. Consultar o comando get periodicamente é a forma de descobrir.