Bird vs Prelude

Bird vs Prelude para Verify

Prelude está construido en torno a un veredicto de riesgo sobre el que puedes bifurcar, y Bird no tiene equivalente. Las dos API son lo suficientemente similares como para que migrar sea, en su mayoría, renombrar. Esta página trata sobre cuál de esos dos hechos importa más para lo que estás construyendo.

Lee la guía de migración Ver Bird Verify

En lo que Prelude destaca.
En qué se diferencia Bird.

En lo que Prelude destaca

Un veredicto sobre el que puedes bifurcar. La llamada de creación acepta señales de IP, dispositivo y huella digital, y responde con un veredicto de enrutamiento de success, retry, challenged, blocked o shadow_blocked, con un motivo cuando rechaza. La creación de Bird responde con la verificación en sí: no hay veredicto, no hay objeto de señales y no hay shadow block. Un registro que dependa de esa decisión tiene que tomarla antes de llamar a Bird.

Canales a los que Bird no llega. Llamada de voz, RCS, Viber, Zalo y autenticación silenciosa de red, en más de 230 países. Ambas plataformas soportan SMS, WhatsApp y Telegram, así que la diferencia son esos cinco canales y no toda la oferta: un número al que Prelude llegaba por Viber o Zalo aquí recurre a SMS, lo cual es una cuestión de tasa de entrega que vale la pena medir en un piloto en lugar de descubrirla a pleno volumen.

El mensaje y el respaldo son tuyos para moldear. Una plantilla con variables, un idioma, tu propio ID de remitente y un código personalizado se configuran por solicitud, y max_auto_fallbacks y force_challenge ajustan la escalación por llamada. En Bird, el texto del código es de Bird y el respaldo sigue el plan de canales del país; los remitentes se configuran por canal en lugar de por solicitud, y solo el de email puede ser una dirección propia.

En qué se diferencia Bird

Una verificación fallida te dice qué tipo de fallo fue. Prelude agrupa un código incorrecto y los intentos agotados en un único estado de fallo. Bird responde con un motivo de incorrect_code, expired o attempts_exhausted, y devuelve attempts_remaining junto a él, para que la pantalla pueda indicar al usuario cuántos intentos le quedan sin que tú los cuentes.

Los eventos de entrega son una suscripción de workspace, firmada. Prelude envía a un callback_url que configuras por verificación. Los endpoints de Bird se registran una vez, cada uno suscrito a los tipos de evento que desea, y cada entrega se firma según Standard Webhooks, así que la URL sale del cuerpo de la solicitud y el receptor tiene algo que verificar.

Un agente puede ejecutar el flujo. El servidor MCP alojado de Bird le da a un agente tres herramientas de verificación contra un workspace real: iniciar una, comprobar un código y avanzar al siguiente canal. No puede reconfigurar la política detrás de ellas, lo cual es deliberado y no una omisión.

La matriz

Capacidad por capacidad.

Las dos API tienen una forma similar, así que la mayoría de filas están igualadas y las diferencias son estrechas. Lee la fila de reintentos seguros en comparación con la página de Twilio Verify: es una ventaja de Bird en ambas, porque ninguna de las dos documenta una clave de idempotencia en el create. La capa de riesgo de Prelude es una concesión arriba en lugar de una fila, porque Bird no ofrece nada con qué compararla.

Capability	Bird	Prelude
Solicitud de creación	JSON a /v1/verify/verifications con una clave bearer. El destinatario es to.phone_number o to.email, y llamar a create de nuevo para un destinatario activo reintenta en lugar de iniciar una nueva verificación.	JSON a un endpoint de verificación v2 con una clave bearer. El destinatario es target.type y target.value, y llamar a create de nuevo para un destinatario activo reintenta de la misma manera.
Reintentos seguros	Un encabezado Idempotency-Key en el create hace que un reintento sea seguro.	Su referencia de create no documenta ninguna clave de idempotencia ni encabezado propio, por lo que un reintento tras un timeout puede emitir un segundo código. dispatch_id no lo es: Prelude lo define como el identificador del dispatch que provino del SDK del frontend, que es lo que permite a su capa antifraude vincular las señales capturadas con esta verificación.
Lo que 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 status de failure cubre tanto un código incorrecto como los intentos agotados, con expired_or_not_found como valor separado. Los dos tipos de fallo no se distinguen.
Canales por los que puede llegar un código	Email, SMS, WhatsApp y Telegram. Voz está etiquetado como En despliegue en lugar de lanzado.	Su oferta publicada de canales incluye SMS, voz, RCS, WhatsApp, Telegram, Viber, Zalo y autenticación silenciosa de red, en más de 230 países, con respaldo automático entre ellos.
Eventos de entrega	Un webhook de workspace suscrito a los tipos de evento de verify que indiques, como verify.verification.verified y verify.attempt.delivered, firmado según Standard Webhooks.	Un callback_url configurado por verificación en la solicitud de creación, de modo que el destino viaja con cada llamada.
Control de respaldo	El plan de canales del país establece el orden y se recorre automáticamente, con un temporizador de entrega por intento que lo avanza cuando no llega un estado de entrega. Una llamada de siguiente canal también avanza una verificación bajo demanda.	max_auto_fallbacks y force_challenge ajustan la escalación en la propia solicitud de creación.
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.	Prelude publica SDK de backend para Node.js, Python, Go, Kotlin/Java, Ruby, PHP y C#, y SDK de frontend para Web, Android, iOS, React Native y Flutter, así que la historia del agente es una biblioteca que tu propio runtime invoca.
Longitud del código	options.code_length en la creación; de lo contrario, el valor predeterminado del workspace.	options.code_size en la creación.

La misma verificación

Iniciando una verificación.

Las estructuras son lo bastante parecidas como para que esto sea, en su mayor parte, un cambio de nombres: target pasa a ser to y code_size pasa a ser code_length. Lo que no tiene equivalente en Bird es el objeto signals, dispatch_id entre los datos que lo alimentan, y no hay verdict en la respuesta para bifurcar la lógica. Lo que aparece solo en el lado de Bird es el header Idempotency-Key.

Prelude

verify.ts

const signupId = crypto.randomUUID();

const response = await fetch("https://api.prelude.dev/v2/verification", {
  method:  "POST",
  headers: {
    Authorization:  `Bearer ${process.env.PRELUDE_API_TOKEN}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    target:      { type: "phone_number", value: "+15551234567" },
    dispatch_id: signupId,
    options:     { code_size: 6 },
  }),
});

const verification = await response.json();
console.log(verification.id, verification.status);

Bird

verify.ts

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 },
    },
    { idempotencyKey: signupId },
  )
  .safe();

if (error) console.error(error.message);
else console.log(data.id, data.status);

Coste de migración

Bajo, salvo que uses la capa de riesgo.

Ambas API se basan en el destinatario en lugar de en un ID de verificación, así que las llamadas se portan casi tal cual: target.value pasa a ser to.phone_number o to.email, code_size pasa a ser code_length, y el callback_url por verificación se convierte en un webhook de workspace suscrito a los tipos de evento de verify que indiques. dispatch_id no tiene equivalente, porque pertenece a la capa de riesgo descrita más abajo y no a la mecánica de la llamada de creación, y el create de Bird acepta un header Idempotency-Key que Prelude no documenta.

La capa de riesgo es la parte que no se porta en absoluto. Si bifurcas la lógica según el verdict de Prelude, envías signals con la creación o dependes de un bloqueo en sombra, no hay nada en el lado de Bird a donde mover esa lógica y la decisión tiene que tomarse antes de la llamada. Dimensiona esa brecha primero, porque todo lo demás aquí se resuelve en una tarde.

Lee la guía de migración Ver la superficie de Verify

Preguntas que la gente realmente hace

¿Es Bird una buena alternativa a Prelude?

Si usas Prelude como API de verificación, sí: las llamadas tienen una estructura similar, la migración es casi un cambio de nombres, y Bird te dice más sobre un check fallido que Prelude. Si usas Prelude como producto antifraude, no. Los signals, el verdict de enrutamiento y el bloqueo en sombra no tienen equivalente en Bird, y esa es la cuestión que hay que resolver antes que cualquier otra cosa.

¿Qué pasa con los signals y el verdict de Prelude?

Nada se traslada. El create de Bird no acepta un objeto signals y responde con la verificación en lugar de una decisión, así que una integración que condiciona los registros al verdict de Prelude tiene que tomar esa decisión por sí misma antes de llamar a Bird. Lo que Bird ofrece en ese ámbito es más limitado y mayormente configuración: habilitación por país para que puedas desactivar destinos que nunca atiendes, y límites de envío y check a nivel de plataforma.

¿Pierdo reintentos seguros al migrar?

Los ganas. La referencia del create de Prelude no documenta ninguna clave de idempotencia ni header propio, y dispatch_id no lo es: es el identificador del dispatch que proviene de su SDK de front-end, que su capa de fraude usa para vincular las señales capturadas con una verificación. El create de Bird acepta un header Idempotency-Key, y una solicitud repetida vuelve marcada como tal, así que un reintento tras un timeout devuelve la verificación ya en curso en lugar de enviar un segundo código al dispositivo.

¿Qué canales pierdo?

Llamada de voz, RCS, Viber, Zalo y autenticación silenciosa de red. SMS, WhatsApp y Telegram están en ambas, y Bird añade email, así que la brecha es menor de lo que sugieren los recuentos de canales. Un número al que Prelude llegaba por Viber o Zalo recurre a SMS en Bird, así que mide la tasa de entrega en esos mercados con un piloto en lugar de a pleno volumen.

Próximos pasos

La guía de migración es por donde empezar: mapea la API campo por campo.

Migrar Verify desde PreludeEl create y el check de Prelude mapeados a Bird, los valores de estado traducidos, y un recuento honesto de qué pasa con la capa de riesgo.Bird vs Twilio VerifyLa misma comparación frente al producto de verificación más amplio del mercado.Orquestación de canalesCómo el plan de país decide por qué canal llega un código y en qué orden.Bird para agentes de IAEl servidor MCP alojado, la CLI de Bird, las habilidades de agente y los gemelos Markdown detrás de cada página de documentación.