Bird vs Prelude

Bird vs Prelude pour Verify

Prelude est construit autour d'un verdict de risque sur lequel vous pouvez brancher votre logique, et Bird n'a pas d'équivalent. Les deux API sont par ailleurs suffisamment proches pour que la migration se résume essentiellement à un renommage. Cette page explique lequel de ces deux faits compte le plus pour ce que vous construisez.

Lire le guide de migration Voir Bird Verify

Ce que Prelude fait très bien.
Ce qui différencie Bird.

Ce que Prelude fait très bien

Un verdict sur lequel brancher votre logique. L'appel create accepte des signaux d'IP, d'appareil et d'empreinte, et répond avec un verdict de routage : success, retry, challenged, blocked ou shadow_blocked, accompagné d'une raison en cas de refus. Le create de Bird répond avec la vérification elle-même : pas de verdict, pas d'objet signals, pas de shadow block. Une inscription qui conditionne l'accès sur cette décision doit la prendre avant d'appeler Bird.

Des canaux que Bird ne couvre pas. Appel vocal, RCS, Viber, Zalo et authentification réseau silencieuse, dans plus de 230 pays. Les deux plateformes prennent en charge SMS, WhatsApp et Telegram, donc l'écart porte sur ces cinq canaux plutôt que sur l'ensemble : un numéro que Prelude atteignait via Viber ou Zalo bascule ici sur SMS, ce qui est une question de taux de livraison à mesurer en pilote plutôt qu'à découvrir en pleine charge.

Le message et le repli sont à votre main. Un template avec variables, une locale, votre propre sender ID et un code personnalisé sont tous configurables par requête, et max_auto_fallbacks et force_challenge ajustent l'escalade à chaque appel. Chez Bird, le texte du code est celui de Bird et le repli suit le plan de canaux du pays ; les expéditeurs sont configurés par canal plutôt que par requête, et seul celui de l'e-mail peut être une adresse à vous.

Ce qui différencie Bird

Un check échoué précise le type d'échec. Prelude regroupe un code erroné et des tentatives épuisées en un seul statut d'échec. Bird répond avec une raison : incorrect_code, expired ou attempts_exhausted, accompagnée de attempts_remaining, afin que l'écran puisse indiquer à l'utilisateur combien de tentatives il lui reste sans les compter vous-même.

Les événements de livraison sont un abonnement du workspace, signé. Prelude envoie vers une callback_url définie par vérification. Les endpoints de Bird sont enregistrés une fois, chacun abonné aux types d'événements souhaités, et chaque livraison est signée selon Standard Webhooks : l'URL quitte le corps de la requête et le récepteur dispose d'un élément à vérifier.

Un agent peut exécuter le flux. Le serveur MCP hébergé de Bird donne à un agent trois outils de vérification sur un workspace réel : démarrer une vérification, vérifier un code et passer au canal suivant. Il ne peut pas reconfigurer la politique sous-jacente, ce qui est délibéré et non un oubli.

La matrice

Fonctionnalité par fonctionnalité.

Les deux API ont une structure similaire, donc la plupart des lignes sont à égalité et les différences sont minces. Lisez la ligne des retries sécurisés en regard de la page Twilio Verify : c'est un avantage Bird sur les deux, car aucun des deux create ne documente de clé d'idempotence. La couche de risque de Prelude est une concession ci-dessus plutôt qu'une ligne, car Bird ne propose rien de comparable.

Capability	Bird	Prelude
Requête create	JSON vers /v1/verify/verifications avec une clé bearer. Le destinataire est to.phone_number ou to.email, et appeler create à nouveau pour un destinataire actif relance la vérification au lieu d'en démarrer une nouvelle.	JSON vers un endpoint de vérification v2 avec une clé bearer. Le destinataire est target.type et target.value, et appeler create à nouveau pour un destinataire actif relance de la même manière.
Retries sécurisés	Un en-tête Idempotency-Key sur le create rend un retry sécurisé.	Leur référence create ne documente ni clé d'idempotence ni en-tête dédié, donc un retry après un timeout peut générer un second code. dispatch_id n'en est pas un : Prelude le définit comme l'identifiant du dispatch provenant du SDK front-end, ce qui permet à leur couche anti-fraude d'associer les signaux capturés à cette vérification.
Ce qu'un check échoué vous indique	success est false avec une raison : incorrect_code, expired ou attempts_exhausted, accompagnée de attempts_remaining.	Un statut failure couvre à la fois un code erroné et des tentatives épuisées, avec expired_or_not_found comme valeur distincte. Les deux types d'échec ne sont pas différenciés.
Canaux par lesquels un code peut arriver	E-mail, SMS, WhatsApp et Telegram. La voix est indiquée comme « En cours de déploiement » plutôt que disponible.	Leur mix de canaux publié comprend SMS, voix, RCS, WhatsApp, Telegram, Viber, Zalo et authentification réseau silencieuse, dans plus de 230 pays, avec repli automatique entre eux.
Événements de livraison	Un webhook de workspace abonné aux types d'événements verify que vous spécifiez, tels que verify.verification.verified et verify.attempt.delivered, signé selon Standard Webhooks.	Une callback_url définie par vérification dans la requête create, de sorte que la destination accompagne chaque appel.
Contrôle du repli	Le plan de canaux du pays définit l'ordre et est parcouru automatiquement, avec un timer de livraison par tentative qui avance au canal suivant en l'absence de statut de livraison. Un appel next-channel fait également avancer une vérification à la demande.	max_auto_fallbacks et force_challenge ajustent l'escalade directement dans la requête create.
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.	Prelude publie des SDK backend pour Node.js, Python, Go, Kotlin/Java, Ruby, PHP et C#, ainsi que des SDK frontend pour Web, Android, iOS, React Native et Flutter : côté agent, c'est donc une bibliothèque que votre propre runtime appelle.
Longueur du code	options.code_length à la création, sinon la valeur par défaut du workspace.	options.code_size à la création.

La même vérification

Lancer une vérification.

Les structures sont suffisamment proches pour que ce soit essentiellement un renommage : target devient to et code_size devient code_length. Ce qui n'a pas d'équivalent chez Bird, c'est l'objet signals, dispatch_id parmi les éléments qui l'alimentent, et il n'y a pas de verdict dans la réponse pour conditionner le flux. Ce qui n'apparaît que côté Bird, c'est le 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);

Coût de migration

Faible, sauf si vous utilisez la couche de risque.

Les deux API s'appuient sur le destinataire plutôt que sur un ID de vérification, donc les appels se portent quasiment tels quels : target.value devient to.phone_number ou to.email, code_size devient code_length, et le callback_url par vérification devient un webhook de workspace abonné aux types d'événements verify que vous désignez. dispatch_id n'a pas d'équivalent, car il appartient à la couche de risque sous-jacente plutôt qu'à la mécanique de l'appel create, et le create de Bird accepte un header Idempotency-Key que celui de Prelude ne documente pas.

La couche de risque est la partie qui ne se porte pas du tout. Si vous conditionnez votre logique sur le verdict de Prelude, envoyez des signals avec le create, ou comptez sur un shadow block, il n'y a rien côté Bird pour y déplacer cette logique et la décision doit être prise avant l'appel. Évaluez cet écart en premier, car tout le reste ici se fait en un après-midi.

Lire le guide de migration Voir la surface Verify

Questions réellement posées

Bird est-il une bonne alternative à Prelude ?

Si vous utilisez Prelude comme API de vérification, oui : les appels ont une structure similaire, le portage se résume presque à un renommage, et Bird vous en dit plus sur un échec de vérification que Prelude. Si vous utilisez Prelude comme produit anti-fraude, non. Les signals, le verdict de routage et le shadow block n'ont pas d'équivalent chez Bird, et c'est la question à trancher avant toute autre chose.

Que deviennent les signals et le verdict de Prelude ?

Rien n'est repris. Le create de Bird n'accepte pas d'objet signals et renvoie la vérification plutôt qu'une décision, donc une intégration qui conditionne les inscriptions au verdict de Prelude doit prendre cette décision elle-même avant d'appeler Bird. Ce que Bird propose dans cet espace est plus restreint et relève surtout de la configuration : activation par pays pour couper les destinations que vous ne desservez jamais, et plafonds d'envoi et de vérification de la plateforme.

Est-ce que je perds les tentatives sécurisées en migrant ?

Vous les gagnez. La référence du create de Prelude ne documente aucune clé d'idempotence ni aucun header dédié, et dispatch_id n'en est pas une : c'est l'identifiant du dispatch issu de leur SDK front-end, que leur couche de fraude utilise pour associer les signaux capturés à une vérification. Le create de Bird accepte un header Idempotency-Key, et une requête rejouée revient marquée comme telle, de sorte qu'une nouvelle tentative après un timeout renvoie la vérification déjà en cours au lieu d'envoyer un second code sur le terminal.

Quels canaux est-ce que je perds ?

L'appel vocal, RCS, Viber, Zalo et l'authentification réseau silencieuse. SMS, WhatsApp et Telegram sont disponibles sur les deux, et Bird ajoute l'e-mail, donc l'écart est plus étroit que le nombre de canaux ne le suggère. Un numéro que Prelude atteignait via Viber ou Zalo bascule sur SMS chez Bird, alors mesurez le taux de livraison pour ces marchés dans un pilote plutôt qu'en plein volume.

Étapes suivantes

Le guide de migration est le point de départ : il cartographie l'API champ par champ.

Migrer Verify depuis PreludeLe create et le check de Prelude transposés chez Bird, les valeurs de statut traduites, et un compte rendu honnête de ce qu'il advient de la couche de risque.Bird vs Twilio VerifyLa même comparaison face au produit de vérification le plus étendu du marché.Orchestration des canauxComment le plan pays détermine 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.