Twilio Verify Events llega a GA y apaga Attempt DLR: si tu bot manda OTP, revisa que no esté escuchando un canal muerto

Twilio anunció el 4 de noviembre que Verify Events ya está en disponibilidad general (GA). El anuncio no trae funciones nuevas, pero cierra un cambio que muchos bots dejaron pasar: los eventos Attempt DLR, que reportaban si el código de verificación llegó por SMS o WhatsApp, quedaron fuera. Si tu bot manda códigos OTP con Twilio Verify y tus alertas de entrega dependían de esos eventos, es muy probable que lleven semanas sin recibir nada. Y sin un solo error, porque Twilio no rechaza la suscripción: simplemente deja de mandar.

Qué anunció Twilio

El changelog del 4 de noviembre es corto. Dice que la versión GA incluye "todas las correcciones" de los errores que reportaron los clientes en la beta y que "no se introdujo funcionalidad nueva". La parte importante viene en el segundo punto: el tipo de evento Attempt DLR se deprecó como parte de este lanzamiento, el 21 de septiembre de 2026, y esa misma deprecación también detuvo las actualizaciones de estado DLR dentro de Verify Events.

Las fechas no cuadran del todo entre los dos avisos. El aviso original, publicado el 22 de septiembre, dice que Attempt DLR quedaría descontinuado después del 22 de septiembre a las 22:00 UTC (16:00 en la Ciudad de México) y que a partir de ese momento Twilio "puede dejar de enviar" esos eventos aunque tengas una suscripción activa. Los demás tipos de evento de la misma suscripción siguen llegando normal. Sea el 21 o el 22, el resultado es el mismo: hoy la documentación de Attempt DLR marca los cinco tipos como descontinuados.

Qué significa "descontinuado" en Event Streams

Twilio maneja cuatro estados para un tipo de evento: disponible, deprecado, restringido y descontinuado. Según su guía del ciclo de vida, un tipo descontinuado ya no llega a las suscripciones existentes y no se puede agregar a una suscripción nueva ni a una que ya tengas. Si una suscripción mezcla varios tipos, los que siguen disponibles se entregan sin problema.

Ese es el detalle peligroso. Si tu suscripción tenía attempt-dlr.delivered junto con verification.approved, la segunda sigue llegando y todo parece estar bien. Lo único que delata el problema es que tu tablero de entrega se quedó plano, y un tablero plano a las tres de la mañana se parece mucho a "no hubo tráfico".

Los tipos afectados son estos cinco, todos con el prefijo com.twilio.accountsecurity.verify.:

attempt-dlr.sent
attempt-dlr.delivered
attempt-dlr.read
attempt-dlr.undelivered
attempt-dlr.failed

El reemplazo: Message Status Stream

Twilio lanzó el piloto de los eventos de estado de mensaje el 27 de febrero de 2026, y el 1 de abril publicó una versión 2 con etiquetas. La documentación de Message Status Stream lista cinco eventos que se corresponden uno a uno con los viejos:

Antes (descontinuado)	Ahora	Cuándo se dispara, según Twilio
`attempt-dlr.sent`	`message.sent`	El proveedor del canal aceptó el mensaje; la entrega todavía no está confirmada
`attempt-dlr.delivered`	`message.delivered`	El proveedor confirma que llegó al usuario
`attempt-dlr.read`	`message.read`	El usuario abrió o leyó el mensaje. No existe para SMS
`attempt-dlr.undelivered`	`message.undelivered`	El proveedor reporta que no se pudo entregar
`attempt-dlr.failed`	`message.failed`	La entrega falló y no habrá más intentos salvo que mandes uno nuevo

Diagrama que relaciona cada evento attempt-dlr descontinuado de Twilio Verify con su equivalente message.* y los tres pasos para migrar un bot

El payload se parece bastante al viejo: account_sid, service_sid, verification_sid, attempt_sid, channel, to, mcc, mnc, number_segments, has_fallback e is_fallback. Los cambios prácticos son dos. El estado viene en message_status, mientras que en los ejemplos de Attempt DLR venía en dlr_status. Y la versión 2 agrega tags: pares clave-valor que mandas al iniciar la verificación y que regresan en el evento. Para un bot de WhatsApp eso sirve, por ejemplo, para meter el ID de la conversación o del flujo y cruzar después qué códigos no llegaron sin tener que armar una tabla de equivalencias.

Los canales soportados son SMS, WhatsApp, RCS y voz, según la página general de Verify Events. Twilio aclara además que el estado de un mensaje no siempre llega al instante: si el proveedor se tarda, Verify lo vuelve a consultar varias veces durante hasta una hora.

No confundas el estado del mensaje con el de la verificación

Verify Events tiene dos flujos distintos y conviene tener claro cuál usar. El flujo de verificación sigue el ciclo de vida del OTP: pending, approved, canceled, expired y max-attempts-reached. Por defecto una verificación expira a los 10 minutos, y el evento de máximo de intentos se dispara después de 5 o más intentos de envío o de revisión. El flujo de mensajes te dice si el código llegó al teléfono.

Hay un antecedente que explica por qué Twilio empuja hacia Message Status. Desde el 1 de abril de 2026, los clientes nuevos del flujo de verificación ya no reciben actualizaciones de delivery_status en cada intento: el valor se queda fijo en SENT y el campo error_code desaparece. Twilio dice que para el estado de entrega hay que usar Message Status. Mi lectura del aviso de GA es que la frase sobre "detener las actualizaciones de estado DLR" extiende ese corte de forma general, aunque Twilio no lo explica con más detalle. Si tu código lee send_code_attempts[].delivery_status esperando ver DELIVERED, revísalo.

Cómo migrar tu bot

No lo probé en una cuenta propia. Esto sale de la documentación oficial de Twilio.

Confirma que el servicio tenga Verify Events encendido. En la consola es la opción "Verify Events Subscribed service" del servicio. Por API es el parámetro VerifyEventSubscriptionEnabled del servicio, según la guía de onboarding.
Edita tu suscripción en Event Streams. Agrega los cinco tipos message.* (la versión 2 si quieres tags) y quita los attempt-dlr.*, que ya no aportan nada.
Actualiza el consumidor. En tu webhook o en tu lector de Kinesis cambia el filtro por type y lee data.message_status. Si usas webhook, Twilio recomienda poner Batch en falso para procesar cada evento por separado.
Revisa alertas y reportes. Cualquier métrica de tasa de entrega por país u operador que salía de Attempt DLR hay que reconstruirla con los eventos nuevos. Para rellenar el hueco puedes usar la API de Verification Attempts, que no es en tiempo real, sigue en beta pública, tiene un límite de 100 solicitudes por minuto y solo guarda los últimos 30 días. Como el corte fue a finales de septiembre, las primeras semanas sin eventos ya quedaron fuera de esa ventana.
Usa los campos de fallback. has_fallback te dice si hay un canal alterno disponible cuando el mensaje falla, e is_fallback si ese mensaje ya es el reintento. Con eso tu bot puede decidir si ofrece "¿te lo mando por SMS?" o si espera.

Verify Events no tiene costo adicional para los clientes de Verify, así que el cambio no sube la factura.

Mi lectura

Esto no es un cambio de API que truene con un 400 y te obligue a enterarte. Es un silencio, y los silencios son lo peor que le puede pasar a un sistema de OTP: el usuario no recibe su código por WhatsApp, abandona el registro y tu alerta de "entregas fallidas" no suena porque ya no le llega nada que contar. Que el anuncio de GA salga seis semanas después del corte, en un changelog de dos viñetas, no ayuda.

Si operas un bot con login por OTP, la tarea de hoy es corta: abre tu suscripción de Event Streams y busca attempt-dlr. Si aparece, ya sabes por qué tus gráficas de entrega se ven tan tranquilas.