Bird vs Prelude

Bird vs Prelude per Verify

Prelude è costruito attorno a un verdetto di rischio su cui si può fare branching, e Bird non ha un equivalente. Le due API sono per il resto abbastanza simili da rendere la migrazione poco più di una rinomina. Questa pagina spiega quale di questi due fatti conta di più per ciò che stai costruendo.

Leggi la guida alla migrazione Scopri Bird Verify

In cosa eccelle Prelude.
In cosa Bird è diverso.

In cosa eccelle Prelude

Un verdetto su cui fare branching. La chiamata create accetta segnali IP, dispositivo e fingerprint e risponde con un verdetto di routing: success, retry, challenged, blocked o shadow_blocked, con una motivazione quando rifiuta. La create di Bird risponde con la verifica stessa: nessun verdetto, nessun oggetto signals e nessun shadow block. Un flusso di registrazione che dipende da quella decisione deve prenderla prima di chiamare Bird.},{

Canali che Bird non raggiunge. Chiamata vocale, RCS, Viber, Zalo e autenticazione silenziosa di rete, in oltre 230 Paesi. Entrambe le piattaforme supportano SMS, WhatsApp e Telegram, quindi il divario riguarda quei cinque canali e non l'intero mix: un numero che Prelude raggiungeva via Viber o Zalo qui ricade sugli SMS, una questione di tasso di consegna che vale la pena misurare in un pilota piuttosto che scoprire a pieno volume.

Il messaggio e il fallback sono sotto il vostro controllo. Un template con variabili, una lingua, il vostro sender ID e un codice personalizzato sono tutti configurabili per richiesta, e max_auto_fallbacks e force_challenge regolano l'escalation per ogni chiamata. Su Bird il testo del passcode è quello di Bird e il fallback segue il piano canale del Paese; i mittenti si configurano per canale anziché per richiesta, e solo quello email può essere un indirizzo vostro.

In cosa Bird è diverso

Un check fallito indica il tipo di errore. Prelude unifica codice errato e tentativi esauriti in un unico stato di fallimento. Bird risponde con una motivazione: incorrect_code, expired o attempts_exhausted, e restituisce anche attempts_remaining, così la schermata può indicare all'utente quanti tentativi restano senza doverli contare voi.

Gli eventi di consegna sono una sottoscrizione workspace, firmata. Prelude invia a un callback_url impostato per ogni verifica. Gli endpoint di Bird si registrano una sola volta, ciascuno sottoscritto ai tipi di evento desiderati, e ogni consegna è firmata secondo Standard Webhooks, così l'URL esce dal corpo della richiesta e il ricevente ha qualcosa da verificare.

Un agente può eseguire il flusso. Il server MCP ospitato da Bird fornisce a un agente tre strumenti di verifica su un workspace reale: avviare una verifica, controllare un codice e passare al canale successivo. Non può riconfigurare la policy che li governa, ed è una scelta deliberata, non un'omissione.

La matrice

Funzionalità per funzionalità.

Le due API hanno una struttura simile, quindi la maggior parte delle righe è alla pari e le differenze sono limitate. Leggete la riga safe-retries confrontandola con la pagina Twilio Verify: è un punto a favore di Bird in entrambi i casi, perché nessuna delle due create documenta una chiave di idempotenza. Il layer di rischio di Prelude è una concessione fatta sopra e non una riga, perché Bird non offre nulla di paragonabile.

Capability	Bird	Prelude
Richiesta create	JSON a /v1/verify/verifications con una bearer key. Il destinatario è to.phone_number o to.email, e chiamare di nuovo create per un destinatario attivo riprova anziché avviare una nuova verifica.	JSON a un endpoint di verifica v2 con una bearer key. Il destinatario è target.type e target.value, e chiamare di nuovo create per un destinatario attivo riprova allo stesso modo.
Retry sicuri	Un header Idempotency-Key sulla create rende sicuro il retry.	La documentazione della loro create non riporta alcuna chiave di idempotenza né un header dedicato, quindi un retry dopo un timeout può generare un secondo passcode. dispatch_id non è una chiave di idempotenza: Prelude lo definisce come l'identificatore del dispatch proveniente dall'SDK front-end, che è ciò che consente al loro layer antifrode di associare i segnali catturati a questa verifica.
Cosa comunica un check fallito	success è false con una motivazione: incorrect_code, expired o attempts_exhausted, e attempts_remaining accanto.	Uno stato failure copre sia un codice errato sia i tentativi esauriti, con expired_or_not_found come valore separato. I due tipi di fallimento non vengono distinti.
Canali su cui può arrivare un passcode	Email, SMS, WhatsApp e Telegram. La voce è indicata come In fase di rilascio anziché disponibile.	Il mix di canali pubblicato comprende SMS, voce, RCS, WhatsApp, Telegram, Viber, Zalo e autenticazione silenziosa di rete, in oltre 230 Paesi, con fallback automatico tra di essi.
Eventi di consegna	Un webhook workspace sottoscritto ai tipi di evento verify che indicate, come verify.verification.verified e verify.attempt.delivered, firmato secondo Standard Webhooks.	Un callback_url impostato per ogni verifica nella richiesta create, così la destinazione viaggia con ogni chiamata.
Controllo del fallback	Il piano canale del Paese stabilisce l'ordine e viene seguito automaticamente, con un timer di consegna per tentativo che avanza quando non arriva uno stato di consegna. Una chiamata next-channel fa avanzare una singola verifica anche on demand.	max_auto_fallbacks e force_challenge regolano l'escalation direttamente nella richiesta create.
Server MCP ospitato	Tre strumenti di verifica sul server ospitato su mcp.bird.com: avviare una verifica, controllare un codice e passare al canale successivo. La configurazione non è tra questi.	Prelude pubblica SDK backend per Node.js, Python, Go, Kotlin/Java, Ruby, PHP e C#, e SDK frontend per Web, Android, iOS, React Native e Flutter, quindi la storia dell'agente è una libreria che il vostro runtime chiama.
Lunghezza del codice	options.code_length nella creazione, altrimenti il valore predefinito del workspace.	options.code_size nella creazione.

La stessa verifica

Avviare una verifica.

Le strutture sono abbastanza simili da ridursi per lo più a una ridenominazione: target diventa to e code_size diventa code_length. Ciò che non ha un equivalente in Bird è l'oggetto signals, dispatch_id tra gli elementi che lo alimentano, e non c'è alcun verdict nella risposta su cui ramificare la logica. Ciò che appare solo lato Bird è l'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);

Costo di migrazione

Basso, a meno che non si utilizzi il livello di rischio.

Entrambe le API si basano sul destinatario anziché su un ID di verifica, quindi le chiamate si trasferiscono quasi così come sono: target.value diventa to.phone_number o to.email, code_size diventa code_length e il callback_url per singola verifica diventa un webhook del workspace sottoscritto ai tipi di evento verify indicati. dispatch_id non ha una corrispondenza, perché appartiene al livello di rischio sottostante e non alla meccanica della chiamata di creazione, e la create di Bird accetta un header Idempotency-Key che quella di Prelude non documenta.

Il livello di rischio è la parte che non è affatto un porting. Se si ramifica la logica sul verdict di Prelude, si inviano signals con la creazione o ci si affida a un blocco shadow, lato Bird non c'è nulla su cui spostare quella logica e la decisione deve avvenire prima della chiamata. Valutate prima questa lacuna, perché tutto il resto si risolve in un pomeriggio.

Leggi la guida alla migrazione Scopri l'interfaccia Verify

Domande che le persone fanno davvero

Bird è una buona alternativa a Prelude?

Se utilizzate Prelude come API di verifica, sì: le chiamate hanno una struttura simile, il porting è quasi una ridenominazione e Bird fornisce più informazioni di Prelude su un controllo fallito. Se utilizzate Prelude come prodotto antifrode, no. I signals, il routing verdict e il blocco shadow non hanno equivalenti in Bird, e questa è la questione da risolvere prima di qualsiasi altra cosa.

Cosa succede ai signals e al verdict di Prelude?

Nulla viene trasferito. La create di Bird non accetta un oggetto signals e risponde con la verifica anziché con una decisione, quindi un'integrazione che subordina le registrazioni al verdict di Prelude deve prendere quella decisione autonomamente prima di chiamare Bird. Ciò che Bird offre in quest'ambito è più limitato e per lo più configurabile: abilitazione per paese, così da disattivare le destinazioni non servite, e limiti di invio e controllo a livello di piattaforma.

Perdo i tentativi sicuri con la migrazione?

Li guadagnate. La documentazione della create di Prelude non prevede chiave di idempotenza né un header dedicato, e dispatch_id non lo è: è l'identificatore del dispatch proveniente dal loro SDK front-end, che il livello antifrode usa per abbinare i segnali acquisiti a una verifica. La create di Bird accetta un header Idempotency-Key e una richiesta ripetuta viene restituita contrassegnata come tale, quindi un tentativo dopo un timeout restituisce la verifica già in corso anziché inviare un secondo codice al dispositivo.

Quali canali perdo?

Chiamata vocale, RCS, Viber, Zalo e autenticazione silenziosa di rete. SMS, WhatsApp e Telegram sono disponibili su entrambi, e Bird aggiunge l'email, quindi il divario è più ridotto di quanto suggeriscano i conteggi dei canali. Un numero che Prelude raggiungeva tramite Viber o Zalo ricade su SMS con Bird: misurate il tasso di consegna per quei mercati in un pilota prima di passare al volume pieno.

Prossimi passi

La guida alla migrazione è il punto di partenza: mappa l'API campo per campo.

Migrare Verify da PreludeLa create e la check di Prelude mappate su Bird, i valori di stato tradotti e un resoconto onesto di cosa succede al livello di rischio.Bird vs Twilio VerifyLo stesso confronto con il prodotto di verifica più diffuso sul mercato.Orchestrazione dei canaliCome il piano paese decide su quale canale arriva il codice e in quale ordine.Bird per agenti AIIl server MCP hosted, la CLI di Bird, le competenze degli agenti e i twin Markdown dietro ogni pagina della documentazione.