Bird vs Twilio

Bird vs Twilio pour Verify

Twilio Verify est le produit le plus large et cette page le dit dès le départ. Bird Verify est plus ciblé et plus simple : un seul appel de création sans Service dans le chemin, un en-tête d'idempotence inclus, et un échec de vérification qui vous indique si le code était incorrect ou si les tentatives sont épuisées. Voici où chacun s'inscrit.

Lire le guide de migration Voir Bird Verify

Ce en quoi Twilio Verify excelle.
Ce qui distingue Bird.

Ce en quoi Twilio Verify excelle

Des canaux que Bird ne couvre pas. Un code dicté par appel vocal, et une vérification réseau silencieuse qui authentifie un appareil sans que l'utilisateur ne saisisse quoi que ce soit. Bird Verify envoie par e-mail, SMS, WhatsApp et Telegram ; son propre canal vocal est indiqué comme en cours de déploiement plutôt que livré, et il ne propose aucun équivalent silencieux.

Une couche anti-fraude intégrée à la requête. RiskCheck et l'adresse IP de l'appareil accompagnent l'appel de création, Fraud Guard se positionne derrière en tant que paramètre de Service avec trois niveaux de protection, et Twilio répond avec une décision fondée sur ces deux éléments. Bird n'expose rien de tel via l'API, donc un parcours d'inscription qui repose sur cette décision doit la prendre avant d'appeler Bird.

Le message est le vôtre. Un template, une locale et un nom convivial sont des paramètres par requête, et un Service regroupe la longueur du code, sa durée de vie et les limites de débit sous un ID que vous choisissez à chaque appel. Chez Bird, ce sont des paramètres de workspace, et le texte du code est celui de Bird ; le canal e-mail fait exception : vous pouvez envoyer depuis un domaine vérifié qui vous appartient.

Ce qui distingue Bird

Une tentative qui ne peut pas envoyer un second code. Un en-tête Idempotency-Key sur la création rend la répétition sûre, et une requête rejouée revient identifiée comme telle. La création Twilio Verify ne documente aucune clé d'idempotence, donc une nouvelle tentative après un timeout peut délivrer deux codes au même appareil.

Un échec de vérification précise le type d'erreur et le nombre de tentatives restantes. Bird répond avec une raison incorrect_code, expired ou attempts_exhausted, accompagnée de attempts_remaining, pour que l'écran puisse indiquer à l'utilisateur qu'il lui reste deux essais. Twilio signale bien les tentatives épuisées, avec un statut max_attempts_reached, mais un code erroné avec des essais restants est simplement pending et aucun champ n'indique le décompte.

Pas de segment Service à contourner. Bird s'adresse directement à /v1/verify/verifications, donc il n'y a pas d'ID dans le chemin ni rien à sélectionner par requête. C'est une vraie perte de flexibilité et un vrai gain en termes de simplicité, et le choix dépend de si vous appliquez une seule politique de vérification ou plusieurs.

La matrice

Fonctionnalité par fonctionnalité.

Twilio Verify l'emporte sur l'étendue : plus de canaux, une configuration par requête, et une couche anti-fraude que Bird n'expose pas. Bird l'emporte sur la mécanique précise des deux appels que vous effectuez réellement, et sur ce qu'un agent peut en faire. Les aspects où Bird n'offre rien du tout sont des concessions mentionnées plus haut plutôt que des lignes ici.

Capability	Bird	Twilio Verify
Requête de création	JSON vers /v1/verify/verifications sur votre hôte régional, avec une clé API bearer. Le destinataire est to.phone_number ou to.email.	Encodé en formulaire vers un chemin Verifications sous le Service que vous adressez, avec un Account SID et un auth token en HTTP Basic. Le Service ID fait partie de l'URL.
Tentatives sécurisées	Un en-tête Idempotency-Key sur la création rend la tentative sûre.	La création Verify ne documente aucune clé ni en-tête d'idempotence, donc une nouvelle tentative après un timeout peut émettre un second code au même destinataire.
Ce qu'un échec de vérification vous indique	success est false avec une raison incorrect_code, expired ou attempts_exhausted, accompagnée de attempts_remaining.	Un statut pending, approved, canceled, max_attempts_reached, deleted, failed ou expired, avec un booléen valid associé. Un code erroné laisse la vérification en pending ; l'épuisement des tentatives déclenche max_attempts_reached et Twilio supprime la vérification, donc la vérification suivante renvoie un 404. Rien n'indique combien de tentatives il reste.
Canaux par lesquels un code peut être envoyé	E-mail, SMS, WhatsApp et Telegram. Le canal vocal est indiqué comme en cours de déploiement plutôt que livré, et il n'existe aucun canal silencieux ou basé sur le réseau.	Leur création accepte email, sms, whatsapp, call, sna et auto. RCS apparaît dans la réponse plutôt que parmi les valeurs que vous pouvez demander.
Configuration par requête	options.code_length et options.channels. La durée de vie du code et les limites de tentatives sont des paramètres de workspace plutôt que des paramètres de requête.	Un Service ID sélectionné par requête définit la longueur du code, sa durée de vie et les limites de débit, et l'appel accepte aussi un template, une locale, un code personnalisé, un hash d'application Android et un nom convivial.
Serveur MCP hébergé	Trois outils de vérification sur le serveur hébergé à mcp.bird.com : démarrer une vérification, vérifier un code, et passer au canal suivant. La configuration n'en fait pas partie, donc un agent peut exécuter des vérifications mais ne peut pas les reconfigurer.	mcp.twilio.com/docs ne nécessite aucun compte et, selon les termes de Twilio, indexe uniquement les spécifications API publiques. Il aide un agent à écrire du code Verify plutôt qu'à gérer un compte Verify.
Événements de livraison	Un webhook de workspace abonné aux types d'événements verify que vous nommez, tels que verify.verification.verified et verify.attempt.delivered, envoyés en JSON signé selon Standard Webhooks.	Des webhooks configurés sur le Service, avec la vérification et son statut postés au fil des changements.
Repli de canal	Le plan de canaux du pays est parcouru automatiquement : un échelon qui échoue passe au canal suivant, et un minuteur de livraison par tentative le fait avancer lorsqu'aucun statut de livraison n'arrive. Un appel canal suivant fait également avancer une vérification à la demande, de sorte que le repli est à la fois une politique et une requête que vous pouvez effectuer.	Le choix automatique du canal et le repli se font côté Twilio, et le Service détient la politique.

La même vérification

Lancer une vérification.

Le Service ID est la différence visible : Twilio adresse un Service dans le chemin, pas Bird, donc les paramètres que ce Service détient migrent vers votre workspace. Le create de Bird accepte aussi un Idempotency-Key, ce qui rend une nouvelle tentative après un timeout sûre plutôt que de générer un second code.

Twilio Verify

verify.ts

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

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, channels: ["sms"] },
    },
    { idempotencyKey: signupId },
  )
  .safe();

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

Coût de migration

Modéré.

Les deux appels se portent proprement. To devient to.phone_number ou to.email, le segment Service sort de l'URL, et votre gestion de statut migre vers un webhook de workspace abonné aux types d'événements verify que vous nommez. Ce qui rend cela modéré plutôt que faible, c'est tout ce que le Service contenait : longueur du code, durée de vie, limites de tentatives et limites de débit deviennent des paramètres du workspace, donc plusieurs Services avec des politiques différentes n'ont pas d'équivalent au sein d'un même workspace.

Deux points nécessitent une décision plutôt qu'un changement de code. Un flux qui utilise l'appel vocal comme repli d'accessibilité, ou la vérification silencieuse comme parcours sans code, n'a pas d'équivalent Bird vers lequel migrer. Et comme un code émis par Twilio ne peut pas être vérifié par Bird, vous basculez au niveau de l'appel create et continuez à router chaque vérification vers celui qui a émis cette vérification jusqu'à expiration de la dernière.

Lire le guide de migration Voir la surface Verify

Questions réellement posées

Bird est-il une bonne alternative à Twilio Verify ?

Cela dépend de si vous utilisez les parties de Twilio Verify que Bird ne propose pas. Si vous envoyez un code par SMS, e-mail ou WhatsApp et le vérifiez, Bird le fait avec moins de composants, rend le create sûr à réessayer et vous indique pourquoi une vérification a échoué. Si vous dépendez du canal vocal, de la vérification silencieuse du réseau, des templates et locales par requête, ou de la couche anti-fraude, Twilio Verify est le meilleur choix et cette page ne prétendra pas le contraire.

Que deviennent mes paramètres de Service Twilio Verify ?

Ils deviennent des paramètres du workspace. La longueur du code reste une option par requête sur Bird, mais la durée de vie, les limites de tentatives et les limites de débit migrent vers le workspace, et il n'y a pas d'ID dans le chemin pour sélectionner une politique différente par appel. Si vous utilisez plusieurs Services avec des politiques réellement différentes, c'est la partie de la migration à dimensionner en premier.

Un agent IA peut-il exécuter des vérifications sur Bird ?

Il peut les exécuter, mais pas les reconfigurer. Le serveur MCP hébergé par Bird sur mcp.bird.com expose trois outils de vérification : lancer une vérification, vérifier un code et passer au canal suivant. La configuration par pays et les paramètres par défaut des vérifications se gèrent dans le tableau de bord Bird plutôt que via l'API publique, et aucun des deux ne fait partie des outils, de sorte qu'un agent peut opérer le flux sans pouvoir modifier la politique qui le sous-tend.

Bird Verify dispose-t-il d'un canal vocal ?

Pas un sur lequel vous pouvez envoyer aujourd'hui. La page Voice OTP de Bird est étiquetée « Déploiement en cours », et les canaux de livraison d'un code sont l'e-mail, le SMS, WhatsApp et Telegram. Twilio Verify propose à la fois un appel vocal et une vérification silencieuse du réseau, donc un flux qui dépend de l'un ou l'autre ne devrait pas planifier une bascule en fonction de la roadmap de Bird.

Puis-je conserver mon propre template de message ?

Non. Twilio Verify accepte un template, une locale et un nom convivial par requête ; Bird n'accepte aucun de ces éléments et contrôle l'identité de l'expéditeur, donc le message que vos utilisateurs voient change lors de la bascule. Le branding sur le canal e-mail est la seule exception. Décidez si c'est acceptable avant de planifier la migration, pas après.

Prochaines étapes

Le guide de migration est celui par lequel commencer : il mappe l'API champ par champ.

Migrer Verify depuis TwilioLes Services, Verifications et VerificationCheck de Twilio Verify mappés sur Bird, avec les paramètres sans équivalent signalés.Bird vs Prelude pour VerifyLa même comparaison avec une plateforme construite autour d'un verdict de risque.Orchestration des canauxComment le plan pays décide sur quel canal un code arrive, et dans quel ordre.Bird pour les agents IALe serveur MCP hébergé, le CLI bird, les compétences d'agent et les jumeaux Markdown derrière chaque page de documentation.