Bird vs Twilio
Bird vs Twilio para Verify
Twilio Verify es el producto más amplio y esta página lo dice desde el principio. Bird Verify es más acotado y simple: una sola llamada de creación sin Service en la ruta, un encabezado de idempotencia incluido, y una verificación fallida que te indica si el código fue incorrecto o si se agotaron los intentos. Aquí se explica dónde encaja cada uno.
En qué destaca Twilio Verify.
En qué se diferencia Bird.
En qué destaca Twilio Verify
Canales que Bird no alcanza. Un código hablado a través de una llamada de voz, y una verificación silenciosa de red que verifica un dispositivo sin que el usuario escriba nada. Bird Verify envía por email, SMS, WhatsApp y Telegram; su propio canal de voz está etiquetado como En despliegue en lugar de disponible, y no tiene ningún equivalente silencioso.
Una capa antifraude en la propia solicitud. RiskCheck y la IP del dispositivo viajan con la llamada de creación, Fraud Guard se sitúa detrás como configuración del Service con tres niveles de protección, y Twilio responde con una decisión basada en ambos. Bird no expone nada de esto en la API, así que un flujo de registro que dependa de esa decisión debe tomarla antes de llamar a Bird.
El mensaje lo escribes tú. Una plantilla, un locale y un nombre descriptivo son parámetros por solicitud, y un Service almacena la longitud del código, su duración y los límites de frecuencia bajo un ID que eliges por llamada. En Bird estos son ajustes del workspace, y el texto del código es de Bird; el canal de email es la excepción, donde puedes enviar desde un dominio verificado propio.
En qué se diferencia Bird
Un reintento que no puede enviar un segundo código. Un encabezado Idempotency-Key en la creación hace que la repetición sea segura, y una solicitud reenviada vuelve marcada como tal. La creación de Twilio Verify no documenta ninguna clave de idempotencia, por lo que un reintento tras un timeout puede poner dos códigos en el mismo dispositivo.
Una verificación fallida indica qué tipo de fallo fue y cuántos intentos quedan. Bird responde con un motivo de incorrect_code, expired o attempts_exhausted, y devuelve attempts_remaining junto a él, para que la pantalla pueda decirle al usuario que le quedan dos intentos. Twilio sí marca los intentos agotados, con un estado max_attempts_reached, pero un código incorrecto con intentos restantes es simplemente pending y ningún campo reporta la cuenta.
Sin segmento Service en la ruta. Bird apunta directamente a /v1/verify/verifications, así que no hay ID en la ruta ni nada que seleccionar por solicitud. Eso supone una pérdida real de flexibilidad y una ganancia real en la cantidad de piezas móviles, y hacia dónde se inclina depende de si gestionas una política de verificación o varias.
La matriz
Funcionalidad por funcionalidad.
Twilio Verify gana en amplitud: más canales, configuración por solicitud y una capa antifraude que Bird no expone. Bird gana en la mecánica precisa de las dos llamadas que realmente haces, y en lo que un agente puede hacer con ellas. Las filas donde Bird no tiene nada son concesiones ya mencionadas arriba, no filas aquí.
| Capability | Bird | Twilio Verify | Who wins? |
|---|---|---|---|
| Solicitud de creación | JSON a /v1/verify/verifications en tu host regional, con una API key de tipo bearer. El destinatario es to.phone_number o to.email. | Form-encoded a una ruta Verifications bajo el Service que indiques, con un Account SID y auth token sobre HTTP Basic. El Service ID es parte de la URL. | |
| Reintentos seguros | Un encabezado Idempotency-Key en la creación hace que el reintento sea seguro. | La creación de Verify no documenta ninguna clave ni encabezado de idempotencia, por lo que un reintento tras un timeout puede emitir un segundo código al mismo destinatario. | |
| Qué te dice una verificación fallida | success es false con un motivo de incorrect_code, expired o attempts_exhausted, y attempts_remaining junto a él. | Un estado de pending, approved, canceled, max_attempts_reached, deleted, failed o expired, con un booleano valid junto a él. Un código incorrecto deja la verificación en pending; al agotarse los intentos se establece max_attempts_reached y Twilio elimina la verificación, por lo que la siguiente comprobación devuelve un 404. Nada reporta cuántos intentos quedan. | |
| Canales por los que puede llegar un código | Email, SMS, WhatsApp y Telegram. El canal de voz está etiquetado como En despliegue en lugar de disponible, y no hay canal silencioso ni basado en red. | Su creación acepta email, sms, whatsapp, call, sna y auto. RCS aparece en la respuesta en lugar de entre los valores que puedes solicitar. | |
| Configuración por solicitud | options.code_length y options.channels. La duración del código y los límites de intentos son ajustes del workspace, no parámetros de la solicitud. | Un Service ID seleccionado por solicitud contiene la longitud del código, su duración y límites de frecuencia, y la llamada también acepta una plantilla, un locale, un código personalizado, un hash de app Android y un nombre descriptivo. | |
| Servidor MCP alojado | Tres herramientas de verificación en el servidor alojado en mcp.bird.com: iniciar una verificación, comprobar un código y avanzar al siguiente canal. La configuración no está entre ellas, así que un agente puede ejecutar verificaciones pero no reconfigurarlas. | mcp.twilio.com/docs no requiere cuenta y, en palabras de Twilio, solo indexa especificaciones públicas de API. Ayuda a un agente a escribir código de Verify en lugar de operar una cuenta de Verify. | |
| Eventos de entrega | Un webhook del workspace suscrito a los tipos de evento de verificación que indiques, como verify.verification.verified y verify.attempt.delivered, entregados como JSON firmado según Standard Webhooks. | Webhooks configurados en el Service, con la verificación y su estado publicados a medida que cambian. | |
| Respaldo de canal | El plan de canales del país se recorre automáticamente: un paso que falla avanza al siguiente canal, y un temporizador de entrega por intento lo avanza cuando no llega ningún estado de entrega. Una llamada de siguiente canal también avanza una verificación bajo demanda, así que el fallback es tanto una política como una solicitud que puedes hacer. | La selección automática de canal y el fallback ocurren del lado de Twilio, y el Service contiene la política. |
La misma verificación
Iniciar una verificación.
El Service ID es la diferencia visible: Twilio incluye un Service en la ruta y Bird no, así que las configuraciones que contiene ese Service pasan a tu workspace. La llamada de creación de Bird también acepta un Idempotency-Key, que es lo que hace seguro reintentar tras un timeout en lugar de generar un segundo código.
Twilio Verify
import twilio from "twilio";
const client = twilio(process.env.TWILIO_ACCOUNT_SID!, process.env.TWILIO_AUTH_TOKEN!);
try {
const verification = await client.verify.v2
.services(process.env.TWILIO_VERIFY_SERVICE_SID!)
.verifications.create({
to: "+15551234567",
channel: "sms",
});
console.log(verification.sid, verification.status);
} catch (err) {
console.error(err);
}
Bird
import { BirdClient } from "@messagebird/sdk";
const bird = new BirdClient({ apiKey: process.env.BIRD_API_KEY! });
const signupId = crypto.randomUUID();
const { data, error } = await bird.verify.verifications
.create(
{
to: { phone_number: "+15551234567" },
options: { code_length: 6, channels: ["sms"] },
},
{ idempotencyKey: signupId },
)
.safe();
if (error) console.error(error.message);
else console.log(data.id, data.status);
Coste de migración
Moderado.
Las dos llamadas se migran sin problemas. To se convierte en to.phone_number o to.email, el segmento del Service sale de la URL, y tu gestión de estados pasa a un webhook de workspace suscrito a los tipos de evento de verify que indiques. Lo que hace esto moderado en vez de bajo es todo lo que contenía el Service: longitud del código, tiempo de vida, límites de intentos y límites de frecuencia se convierten en configuraciones del workspace, así que varios Services con políticas distintas no tienen equivalente dentro de un solo workspace.
Dos cosas requieren una decisión en lugar de un cambio de código. Un flujo que usa la llamada de voz como fallback de accesibilidad, o la verificación silenciosa como vía sin código, no tiene equivalente en Bird al que migrar. Y como un código emitido por Twilio no puede verificarse en Bird, el corte se hace en la llamada de creación y cada verificación sigue dirigiéndose a quien la emitió hasta que la última expire.
Preguntas que la gente realmente hace
¿Es Bird una buena alternativa a Twilio Verify?
¿Qué pasa con la configuración de mi Twilio Verify Service?
¿Puede un agente de IA ejecutar verificaciones en Bird?
¿Tiene Bird Verify un canal de voz?
¿Puedo conservar mi propia plantilla de mensaje?
Próximos pasos
La guía de migración es la mejor para empezar: mapea la API campo por campo.