¿Por qué rechazaron mi verificación toll-free SMS?

Cuando un operador rechaza un expediente, la verificación expone el motivo por separado de los estados de los elementos. denial_reasons contiene la explicación del operador. La lista de requisitos registra lo que suministraste, no qué respuesta causó el rechazo.

El primer lugar donde la gente mira es la lista de requisitos, y no puede responder esto. Entender el porqué ahorra mucho tiempo.

¿Dónde está el motivo del rechazo?

Usa bird sms tfn verifications get para leer la verificación. Devuelve el estado, el remitente que licencia y la respuesta del operador. denial_reasons contiene esa respuesta como texto.

Un detalle a tener en cuenta: los motivos llegan con un rechazo. Cuando un operador pide cambios en lugar de rechazar directamente, la verificación pasa a info_requested y registra el nuevo estado sin motivos adjuntos. Así que una verificación que te pide más información no te dirá qué necesita, y la lista de requisitos es donde miras entonces, para ver qué elementos aún faltan.

¿Por qué la lista de requisitos no puede decir qué respuesta estaba mal?

Porque el operador no decide respuesta por respuesta. Decide el expediente como un todo, y Bird proyecta ese único veredicto sobre cada elemento que suministraste.

En una verificación rechazada, cada elemento suministrado aparece como rejected, haya causado o no el problema. Cada elemento vacío aparece como not_supplied. Nada en la lista está más rechazado que otro elemento. La lista no te da un culpable, así que usa denial_reasons.

Para lo que realmente sirve la lista de requisitos es para la estructura del expediente: qué se pide, qué has respondido y qué falta todavía.

¿Qué pide realmente el operador?

Solicita los requisitos sin nombrar una verificación y obtienes el formulario en blanco: cada elemento que los operadores piden, en el orden en que se presenta. Nombra una con --verification-id y obtienes la misma lista con sus propias respuestas.

Cada elemento incluye un key bajo el cual enviarlo, un label para mostrar a quien deba responderlo, help_text que describe cómo es una buena respuesta, y si la respuesta es required. Los elementos opcionales también se revisan cuando los proporcionas.

Dos respuestas son conjuntos cerrados que vale la pena conocer antes de empezar:

• Estructura legal, una de sole_proprietor, private_profit, public_profit, non_profit o government. Se escriben igual que las cinco estructuras de 10DLC y son deliberadamente una lista separada, porque cada autoridad decide por sí misma qué acepta.
• Volumen mensual, como una banda en lugar de un número: once en total, desde up_to_10 pasando por up_to_1m y up_to_5m, hasta above_5m.

Cada elemento también reporta un state, y una lectura toll-free emite cinco de ellos: not_supplied, supplied, in_review, approved y rejected. Trata el conjunto como abierto, ya que la revisión puede sumar etapas.

¿Cómo sé si está esperando por mí o por el operador?

Dos booleanos en la lectura de requisitos lo responden, y solo uno de ellos es sobre ti.

satisfied es true solo cuando la verificación está aprobada. Una solicitud completa aún puede estar pendiente de aprobación.

needs_input es true cuando el siguiente paso es tuyo. Cubre cuatro situaciones: un elemento obligatorio no tiene respuesta, el operador ha pedido cambios, tu borrador está completo pero nadie lo ha enviado, o un rechazo aún está dentro de su ventana de reenvío.

Ambos en false es la combinación que vale la pena reconocer, porque tiene dos significados. O el operador tiene el expediente y no queda más que esperar, o tu verificación fue rechazada y su ventana de reenvío ya se cerró. resubmit_allowed es lo que distingue esos dos casos, razón suficiente para leerlo siempre que leas un rechazo.

¿Qué significan los seis estados de verificación?

¿Puedo corregir una verificación rechazada?

A veces, y un campo lo responde: una verificación rechazada solo se puede corregir y reenviar mientras resubmit_allowed sea true. Usa el indicador devuelto y el estado de revisión antes de editar o reenviar, en lugar de calcular la elegibilidad solo a partir de una fecha.

Una verificación es editable mientras es un borrador, cuando el operador ha pedido más información y mientras un rechazo aún está dentro de su ventana de reenvío. Todo lo demás está bloqueado, lo que incluye submitted y under_review además de approved, así que los dos estados en los que más tiempo pasas esperando son estados desde los que no puedes editar. Intentarlo de todos modos devuelve un conflicto.

Corregir una respuesta no significa volver a ingresar las demás. Una actualización aplica solo los campos que envías, así que una sola respuesta incorrecta te cuesta esa respuesta, no el expediente.

¿Qué comandos uso?

Seis comandos cubren el ciclo de vida, y un paso falta entre ellos a propósito.

bird sms tfn verifications requirements lee la vista elemento por elemento, y get, create, update, list y cancel hacen lo que sus nombres indican. Enviar una verificación para revisión no está entre ellos: se hace desde el dashboard.

Un atajo que vale la pena conocer mientras llenas el formulario. Pasar --identity-id precarga los requisitos de negocio y contacto desde una parte que ya describiste, y esos vuelven marcados como precargados. Los requisitos de mensajería y opt-in nunca se precargan, porque los redactas nuevos para cada verificación, y cualquier dato que ya hayas registrado para esta verificación prevalece sobre la respuesta de la parte.

Tampoco hay un evento webhook público para el estado de verificación toll-free, así que una suscripción no puede avisarte cuando llega una decisión. Consultar el comando get periódicamente es la forma de enterarte.