Bird vs Prelude
Bird vs Prelude pour Verify
Bird Verify expose la livraison par destinataire et les vérifications de code : créez un code, avancez dans le plan de canaux disponibles et vérifiez la réponse en utilisant le même destinataire. Comparez ce flux avec la fenêtre de vérification et les résultats de risque de Prelude avant de migrer une inscription ou une connexion.
Utilisé chaque jour par des équipes qui
créent des logiciels de classe mondiale.
Quel flux de vérification convient à votre application ?
Quand Prelude convient
La réponse de création de Prelude distingue success, retry, challenged, blocked et shadow_blocked. Ses signaux alimentent les décisions antifraude ; challenged et shadow_blocked nécessitent l'activation du compte. Conservez ou remplacez la décision de risque dont dépend votre application avant de migrer sa livraison de code.
La documentation de Prelude mentionne RCS, Viber, Zalo et l'authentification réseau silencieuse aux côtés de SMS, WhatsApp et Telegram ; sa méthode de requête accepte aussi la voix. Le plan sélectionnable de Bird inclut SMS, WhatsApp, l'e-mail et Telegram. La voix est encore en cours de déploiement et n'est pas proposée comme option de migration client aujourd'hui. Conservez ou repensez toute méthode RCS, Viber, Zalo ou d'authentification silencieuse dont vous dépendez.
Les options de requête de Prelude incluent les modèles, la locale et un identifiant d'expéditeur activé. Les codes personnalisés, une liste explicite de canaux, force_challenge et max_auto_fallbacks nécessitent l'activation du compte. Ces paramètres exigent une décision de migration explicite, pas un simple renommage de champ.
Pourquoi choisir Bird Verify ?
Bird identifie la vérification par le destinataire, y compris une adresse e-mail, un numéro de téléphone ou les deux. Son plan pays détermine les canaux disponibles ; options.channels peut réduire ou réordonner ce plan.
La réponse de vérification de Bird renvoie success, reason et attempts_remaining. Enregistrez success: true dans votre application ; une vérification ultérieure d'un enregistrement finalisé renvoie 404 et n'annule pas ce résultat.
Le serveur MCP hébergé de Bird et les exemples CLI exécutent les opérations de création, de vérification et de canal suivant. Un agent peut demander le canal de livraison suivant avec le même destinataire que son application détient déjà.
La matrice
Comment les API Verify se comparent-elles ?
Comparez l'état du destinataire, la récupération et les décisions de risque. La disponibilité des canaux et les options avancées dépendent de la destination et de l'activation du compte.
| Fonctionnalité | Bird | Prelude | Qui gagne ? |
|---|---|---|---|
| Requête create | JSON avec une clé bearer vers /v1/verify/verifications, avec to.email, to.phone_number ou les deux. | JSON create-or-retry avec une clé bearer et target.type plus target.value. La vérification par e-mail nécessite de contacter Prelude concernant le cas d'usage. | |
| Retries sécurisés | Idempotency-Key rejoue la requête. Les renvois par destinataire réutilisent la vérification active, respectent son délai d'attente et envoient un nouveau code après celui-ci. | Répéter la requête dans une fenêtre de vérification active crée une tentative de réessai. Le guide du cycle de vie documente l'espacement minimal entre les réessais et les limites de tentatives. | |
| Ce qu'un check échoué vous indique | success: false, reason et attempts_remaining. Persistez un résultat réussi avant que la vérification ne soit finalisée. | Le statut de vérification inclut success, failure et expired_or_not_found. Les codes liés à une transaction peuvent aussi renvoyer transaction_missing ou transaction_mismatch. | |
| Canaux par lesquels un code peut arriver | SMS, WhatsApp, e-mail et Telegram, limités au plan pays résolu du destinataire. Voice est encore en cours de déploiement et n'est pas disponible pour le trafic client. | Les canaux de messagerie incluent SMS, RCS, WhatsApp, Telegram, Viber et Zalo, plus l'authentification silencieuse ; method: voice demande un appel téléphonique. La disponibilité dépend du compte et de la destination. | |
| Événements de livraison | Les abonnements d'espace de travail distinguent les événements de vérification et de livraison ; les signatures Standard Webhooks authentifient la charge utile. | options.callback_url sélectionne la destination par requête. Générez une clé de signature pour activer les signatures RSASSA-PSS SHA-256 dans X-Webhook-Signature. | |
| Contrôle du repli | Un échec de livraison fait avancer le plan résolu. Next-channel le fait avancer sur demande et envoie un nouveau code ; les codes précédents restent valides. | max_auto_fallbacks limite les tentatives automatiques supplémentaires et nécessite l'activation du compte. Il est fixé à la création ; un réessai demandé reçoit une nouvelle allocation de cette même limite. | |
| Serveur MCP hébergé | Le serveur MCP hébergé et authentifié exécute les opérations create, check et next-channel ; le CLI bird expose les mêmes opérations. | Les SDK backend de Prelude permettent au code applicatif d'appeler Verify. Son SDK Node expose verification.create et verification.check. | |
| Longueur du code | options.code_length choisit la longueur du code ; sinon le paramètre de l'espace de travail s'applique. | options.code_size accepte de 4 à 8 chiffres et utilise sinon le paramètre du tableau de bord. | |
| Résultat de risque | Limites d'envoi par destinataire, limites de vérification et configuration pays. La réponse de création renvoie une vérification, sans le résultat challenged ou shadow_blocked de Prelude. | Le statut de création et les données de risque permettent de brancher sur le trafic bloqué. reason décrit un blocage ; risk_factors apparaît pour les décisions blocked ou shadow_blocked lorsque des signaux de risque spécifiques sont détectés ; ces champs ne constituent pas une justification pour chaque envoi réussi. |
Qui contrôle la tentative de livraison suivante ?
Bird résout son plan de canaux à partir du destinataire et du pays. Un échec de livraison ou une requête next-channel explicite fait avancer ce plan. Chaque appel explicite avance d'un canal au maximum et envoie un nouveau code ; les codes précédents restent valides pour la vérification active.
Bird : create avec to → plan de canaux résolu → échec de livraison ou next-channel → nouveau code → check avec le même to. Un plan épuisé renvoie NoNextChannel. Enregistrez le succès avant de proposer un nouvel envoi.
Prelude : create avec target et signals → résultat de risque → fenêtre de vérification → route de livraison → réessai automatique ou demandé → vérification du code. Son guide du cycle de vie traite un nouveau create pour le même numéro dans la fenêtre active comme un réessai, pas comme une nouvelle vérification.
La limite de repli de Prelude compte les tentatives automatiques supplémentaires. Une valeur à zéro désactive les réessais automatiques de fournisseur et de canal. La valeur nécessite l'activation et est fixée à la création ; la modifier lors d'un réessai est ignoré, tandis qu'un réessai demandé reçoit une nouvelle allocation de la limite fixée.
Que signifie success dans chaque réponse ?
Le point de terminaison check de Bird renvoie success: true lorsque le code est accepté. HTTP 200 peut aussi contenir success: false et une raison d'échec. Conservez le résultat d'application réussi ; un 404 d'enregistrement finalisé n'est pas une annulation de l'authentification.
Le statut de création success de Prelude signifie qu'une nouvelle fenêtre de vérification a été créée. Son statut de vérification success est le résultat à utiliser pour l'acceptation du code. N'accordez pas l'accès à partir du résultat de création. Les deux appels identifient la cible par son type et sa valeur.
La référence de vérification de Prelude définit aussi transaction_missing et transaction_mismatch pour les codes prelude:psd2. Conservez cette liaison de transaction ou choisissez un remplacement explicite avant de migrer un tel flux.
Quels signaux de risque et vérifications de webhooks doivent survivre à la migration ?
Prelude définit dispatch_id comme “The identifier of the dispatch that came from the front-end SDK.” dans sa référence de création. Fournissez la valeur dispatch réelle du SDK lors de l'utilisation de cette intégration ; un UUID de requête généré par l'application ne le remplace pas.
Le guide anti-fraude de Prelude décrit les signaux fournis par le serveur et les signaux supplémentaires de l'appareil issus de ses SDK frontend. Ses états challenged et shadow_blocked nécessitent une activation du compte. Inventoriez les branches applicatives qui consomment ces résultats.
Les plafonds d'envoi et de vérification de Bird limitent l'utilisation de API. Ils ne remplacent pas un verdict de risque dont dépend votre flux d'inscription. Conservez la décision anti-fraude de l'application autour de la distribution du code.
Prelude signe les charges utiles de webhook avec RSASSA-PSS et SHA-256 après la génération d'une clé de signature dans son tableau de bord. Bird utilise les Standard Webhooks. Conservez la vérification de signature, mais remplacez le vérificateur et le mappage d'événements au lieu de réutiliser la logique d'en-tête de Prelude.
Comment la vérification et la livraison sont-elles facturées ?
There's no plan, seat, or platform fee for Bird Verify. Each delivery is charged at that channel's rate for the destination. A resend, or a fallback that moves delivery to a second channel, is a new send and a new charge.
A verdict compares only published delivery rates with the same channel, destination, currency, billing unit and sender type. Per-success verification fees and per-send charges are Not comparable: your own sends and successful checks determine usage.
Pricing verdict: Not comparable
| Élément publié | Prelude | Politique de facturation de Bird |
|---|---|---|
| Pay As You Go Per verification | 0.032 € Per verification plus message costs. Monthly billing and 10,000 verifications selected. as published | There's no plan, seat, or platform fee for Bird Verify. Les envois par canal sont facturés séparément. Consultez les tarifs en vigueur par canal ci-dessous. |
| Startup Per month | 360 € Per month plus message costs. Monthly billing and 10,000 verifications selected. as published | There's no plan, seat, or platform fee for Bird Verify. Les envois par canal sont facturés séparément. Consultez les tarifs en vigueur par canal ci-dessous. |
| Enterprise Custom volume | Contact sales Contact sales for committed volume pricing. as published | There's no plan, seat, or platform fee for Bird Verify. Les envois par canal sont facturés séparément. Consultez les tarifs en vigueur par canal ci-dessous. |
| SMS (US) Per SMS Destination: US | €0.0043 EUR Message cost for the selected United States destination. Verification charges are separate. as published | There's no plan, seat, or platform fee for Bird Verify. Les envois par canal sont facturés séparément. Consultez les tarifs en vigueur par canal ci-dessous. |
| WhatsApp (US) Per message Destination: US | €0.0028 EUR Message cost for the selected United States destination. Verification charges are separate. as published | There's no plan, seat, or platform fee for Bird Verify. Les envois par canal sont facturés séparément. Consultez les tarifs en vigueur par canal ci-dessous. |
| RCS (US) Per message Destination: US | €0.00 EUR Message cost for the selected United States destination. Verification charges are separate. as published | There's no plan, seat, or platform fee for Bird Verify. Les envois par canal sont facturés séparément. Consultez les tarifs en vigueur par canal ci-dessous. This method is outside Bird’s documented Verify channel plan. |
| Telegram (US) Per message Destination: US | €0.012 EUR Message cost for the selected United States destination. Verification charges are separate. as published | There's no plan, seat, or platform fee for Bird Verify. Les envois par canal sont facturés séparément. Consultez les tarifs en vigueur par canal ci-dessous. |
| Viber (US) Per message Destination: US | €0.007 EUR Message cost for the selected United States destination. Verification charges are separate. as published | There's no plan, seat, or platform fee for Bird Verify. Les envois par canal sont facturés séparément. Consultez les tarifs en vigueur par canal ci-dessous. This method is outside Bird’s documented Verify channel plan. |
Bird a publié les tarifs du canal SMS
Bird's SMS catalogue rates are shown by sender type, per message segment. Carrier fees and sender costs may apply separately. These channel rates are not a total verification quote. SMS pricing; carrier fees.
| Destination | Type d'expéditeur | Par segment SMS |
|---|---|---|
| US | long_code | EUR 0.003 |
| US | long_code | USD 0.0035 |
| US | toll_free | EUR 0.003 |
| US | toll_free | USD 0.0035 |
| US | short_code | EUR 0.006 |
| US | short_code | USD 0.007 |
Bird email pricing and Bird WhatsApp pricing publish the other delivery channels.
La même vérification
Comment démarrer une vérification ?
La ressource de création de Prelude accepte target et options.code_size sur /v2/verification. Le point de terminaison de création de Bird accepte to et options.code_length. Ne fournissez un identifiant dispatch frontend réel que lorsque cette intégration Prelude est utilisée.
Prelude
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" },
options: { code_size: 6 },
}),
});
const verification = await response.json();
console.log(verification.id, verification.status);
Bird
import { BirdClient } from "@messagebird/sdk";
const bird = new BirdClient({ apiKey: process.env.BIRD_API_KEY! });
const { data, error } = await bird.verify.verifications
.create(
{
to: { phone_number: "+15551234567" },
options: { code_length: 6 },
},
)
.safe();
if (error) console.error(error.message);
else console.log(data.id, data.status);
Coût de migration
Que faut-il changer avant la bascule ?
Inventoriez les méthodes, décisions de risque, modèles, identifiants d'expéditeur et vérifications liées aux transactions que votre application utilise. Le guide de migration Prelude recense les champs pris en charge. Un canal voix, RCS, Viber, Zalo ou d'authentification silencieuse dont vous dépendez nécessite une alternative explicite avant de migrer vers Bird.
Dirigez les nouvelles créations vers le fournisseur choisi et conservez les vérifications en cours chez le fournisseur qui a émis le code. Mappez les événements de rappel, installez le vérificateur de signature correspondant et persistez les vérifications réussies. Testez les réessais après expiration, les renvois par l'utilisateur, l'avancement de canal et les vérifications expirées avant la bascule. Consultez la politique d'expéditeur et de message de Bird en lien avec le flux côté destinataire.
Que devez-vous vérifier avant de choisir ?
Bird est-il une alternative à Prelude pour SMS et l'e-mail ?
Un réessai démarre-t-il une nouvelle vérification Prelude ?
Puis-je ajuster la limite de repli de Prelude à chaque réessai ?
Que dois-je stocker après une vérification réussie ?
Mettez-le en pratique.
Poursuivez avec la documentation, les guides et les exemples sur ce sujet. Les ressources sont en anglais.
Étapes suivantes
Commencez par le guide de migration, puis comparez les canaux pris en charge et les unités de facturation.
Intégrez la vérification à votre produit.
Échangez avec notre équipe sur vos canaux, votre flux de vérification et le trafic attendu.