Bird vs Prelude
Bird vs Prelude per Verify
Bird Verify espone consegna basata sul destinatario e controllo del codice: crea un codice, avanza nel piano dei canali disponibili e verifica la risposta usando lo stesso destinatario. Confronta questo flusso con la finestra di verifica e gli esiti di rischio di Prelude prima di spostare una registrazione o un login.
Scelto ogni giorno da team che
creano software di classe mondiale.
Quale flusso di verifica è adatto alla tua applicazione?
Quando Prelude è la scelta giusta
La risposta di creazione di Prelude distingue success, retry, challenged, blocked e shadow_blocked. I suoi segnali alimentano le decisioni antifrode; challenged e shadow_blocked richiedono l'abilitazione dell'account. Mantieni o sostituisci la decisione di rischio su cui la tua applicazione si basa prima di spostare la consegna del codice.
La documentazione di Prelude elenca RCS, Viber, Zalo e l'autenticazione silenziosa di rete insieme a SMS, WhatsApp e Telegram; il suo metodo di richiesta accetta anche la voce. Il piano selezionabile di Bird include SMS, WhatsApp, email e Telegram. La voce è ancora in fase di rilascio e non è un'opzione per la migrazione dei clienti. Valuta se mantenere o riprogettare un metodo RCS, Viber, Zalo o di autenticazione silenziosa su cui fai affidamento.
Le opzioni di richiesta di Prelude includono template, locale e un sender ID abilitato. Codici personalizzati, una lista esplicita di canali, force_challenge e max_auto_fallbacks richiedono l'abilitazione dell'account. Queste impostazioni richiedono una decisione esplicita di migrazione, non una rinomina di campo.
Perché scegliere Bird Verify?
Bird identifica la verifica tramite il destinatario, che può essere un indirizzo email, un numero di telefono o entrambi. Il piano paese determina quali canali sono disponibili; options.channels può ridurre o riordinare quel piano.
La risposta di controllo di Bird restituisce success, reason e attempts_remaining. Salva success: true nella tua applicazione; un controllo successivo di una verifica finalizzata restituisce 404 e non annulla quell'esito.
Il server MCP ospitato e gli esempi CLI di Bird eseguono operazioni di creazione, controllo e canale successivo. Un agente può richiedere il canale di consegna successivo con lo stesso destinatario già presente nella sua applicazione.
La matrice
Come si confrontano le API Verify?
Confronta stato del destinatario, recupero e decisioni di rischio. La disponibilità dei canali e le opzioni avanzate dipendono dalla destinazione e dall'abilitazione dell'account.
| Funzionalità | Bird | Prelude | Chi vince? |
|---|---|---|---|
| Richiesta create | JSON con una bearer key verso /v1/verify/verifications, con to.email, to.phone_number o entrambi. | JSON create-or-retry con una bearer key e target.type più target.value. La verifica via email richiede di contattare Prelude riguardo al caso d'uso. | |
| Retry sicuri | Idempotency-Key ripete la richiesta. I reinvii al destinatario riutilizzano la verifica attiva, ne rispettano il cooldown e inviano un nuovo codice al termine. | Ripetere la richiesta all'interno di una finestra di verifica attiva crea un tentativo di riprovare. La guida al ciclo di vita documenta l'intervallo minimo tra i tentativi e i limiti di tentativo. | |
| Cosa comunica un check fallito | success: false, reason e attempts_remaining. Salva un risultato positivo prima che la verifica venga finalizzata. | Lo stato del controllo include success, failure e expired_or_not_found. I codici legati a una transazione possono anche restituire transaction_missing o transaction_mismatch. | |
| Canali su cui può arrivare un passcode | SMS, WhatsApp, email e Telegram, limitati al piano paese risolto del destinatario. Voice è ancora in fase di rilascio e non è disponibile per il traffico dei clienti. | I canali di messaggistica includono SMS, RCS, WhatsApp, Telegram, Viber e Zalo, più l'autenticazione silenziosa; method: voice richiede una telefonata. La disponibilità dipende dall'account e dalla destinazione. | |
| Eventi di consegna | Le sottoscrizioni dello spazio di lavoro distinguono gli eventi di verifica e di consegna; le firme Standard Webhooks autenticano il payload. | options.callback_url seleziona la destinazione per ogni richiesta. Genera una chiave di firma per abilitare le firme RSASSA-PSS SHA-256 in X-Webhook-Signature. | |
| Controllo del fallback | Un errore di consegna avanza il piano risolto. Next-channel lo avanza su richiesta e invia un nuovo codice; i codici precedenti restano validi. | max_auto_fallbacks limita i tentativi automatici aggiuntivi e richiede l'abilitazione dell'account. È fisso alla creazione; un tentativo richiesto di riprovare ottiene una nuova dotazione dello stesso limite. | |
| Server MCP ospitato | Il server MCP ospitato e autenticato esegue creazione, controllo e canale successivo; la CLI di Bird espone le stesse operazioni. | Gli SDK backend di Prelude permettono al codice applicativo di chiamare Verify. Il suo SDK Node espone verification.create e verification.check. | |
| Lunghezza del codice | options.code_length sceglie la lunghezza del codice; altrimenti si applica l'impostazione dello spazio di lavoro. | options.code_size accetta da 4 a 8 cifre e altrimenti usa l'impostazione della dashboard. | |
| Esito di rischio | Limiti di invio al destinatario, limiti di controllo e configurazione paese. La risposta di creazione restituisce una verifica, senza l'esito challenged o shadow_blocked di Prelude. | Stato di creazione e dati di rischio supportano il branching sul traffico bloccato. reason descrive un blocco; risk_factors appare per decisioni blocked o shadow_blocked quando vengono rilevati segnali di rischio specifici; questi campi non sono una motivazione per ogni invio riuscito. |
Chi controlla il prossimo tentativo di consegna?
Bird risolve il piano dei canali a partire dal destinatario e dal paese. Un errore di consegna o una richiesta esplicita di canale successivo avanza quel piano. Ogni chiamata esplicita avanza di al massimo un canale e invia un nuovo codice; i codici precedenti restano validi per la verifica attiva.
Bird: creazione con to → piano dei canali risolto → consegna fallita o next-channel → nuovo codice → controllo con lo stesso to. Un piano esaurito restituisce NoNextChannel. Salva il successo prima di offrire un altro invio.
Prelude: creazione con target e signals → esito di rischio → finestra di verifica → percorso di consegna → riprovare automatico o richiesto → controllo del codice. La sua guida al ciclo di vita tratta un'altra creazione per lo stesso numero all'interno della finestra attiva come un tentativo di riprovare, non come una nuova verifica.
Il limite di fallback di Prelude conta i tentativi automatici aggiuntivi. Un valore zero disabilita i tentativi automatici di provider e canale. Il valore richiede l'abilitazione ed è fisso alla creazione; modificarlo in un tentativo di riprovare viene ignorato, mentre un tentativo richiesto riceve una nuova dotazione del limite fisso.
Cosa significa success in ciascuna risposta?
L'endpoint di controllo di Bird restituisce success: true quando il codice è accettato. HTTP 200 può anche contenere success: false e un motivo di fallimento. Mantieni l'esito positivo nell'applicazione; un 404 di record finalizzato non è un annullamento dell'autenticazione.
Lo stato di creazione: success di Prelude significa che è stata creata una nuova finestra di verifica. Il suo stato di controllo: success è il risultato da usare per l'accettazione del codice. Non concedere l'accesso dal risultato della creazione. Entrambe le chiamate identificano il target tramite type e value.
Il riferimento check di Prelude definisce anche transaction_missing e transaction_mismatch per i codici prelude:psd2. Conserva quel binding di transazione o scegli un sostituto esplicito prima di migrare un flusso di questo tipo.
Quali segnali di rischio e controlli webhook devono sopravvivere alla migrazione?
Prelude definisce dispatch_id come “The identifier of the dispatch that came from the front-end SDK.” nel suo riferimento create. Fornisci il valore dispatch effettivo del SDK quando usi quell'integrazione; un UUID di richiesta generato dall'applicazione non è un sostituto.
La guida antifrode di Prelude descrive segnali forniti dal server e segnali aggiuntivi dal dispositivo tramite i suoi SDK frontend. I suoi stati challenged e shadow_blocked richiedono l'abilitazione dell'account. Inventaria i rami dell'applicazione che consumano quei risultati.
I limiti di invio e verifica di Bird vincolano l'uso di API. Non sostituiscono un verdetto di rischio da cui dipende il tuo flusso di registrazione. Mantieni la decisione antifrode dell'applicazione attorno alla consegna del codice.
Prelude firma i payload dei webhook con RSASSA-PSS e SHA-256 dopo che una chiave di firma è stata generata nella sua dashboard. Bird usa Standard Webhooks. Mantieni la verifica della firma, ma sostituisci il verificatore e la mappatura degli eventi anziché riutilizzare la logica degli header di Prelude.
Come vengono fatturate la verifica e la consegna?
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
| Voce pubblicata | Prelude | Politica di fatturazione di 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. Gli invii sui canali vengono fatturati separatamente. Consulta le tariffe aggiornate dei canali qui sotto. |
| 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. Gli invii sui canali vengono fatturati separatamente. Consulta le tariffe aggiornate dei canali qui sotto. |
| Enterprise Custom volume | Contact sales Contact sales for committed volume pricing. as published | There's no plan, seat, or platform fee for Bird Verify. Gli invii sui canali vengono fatturati separatamente. Consulta le tariffe aggiornate dei canali qui sotto. |
| 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. Gli invii sui canali vengono fatturati separatamente. Consulta le tariffe aggiornate dei canali qui sotto. |
| 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. Gli invii sui canali vengono fatturati separatamente. Consulta le tariffe aggiornate dei canali qui sotto. |
| 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. Gli invii sui canali vengono fatturati separatamente. Consulta le tariffe aggiornate dei canali qui sotto. 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. Gli invii sui canali vengono fatturati separatamente. Consulta le tariffe aggiornate dei canali qui sotto. |
| 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. Gli invii sui canali vengono fatturati separatamente. Consulta le tariffe aggiornate dei canali qui sotto. This method is outside Bird’s documented Verify channel plan. |
Bird ha pubblicato le tariffe del canale 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.
| Destinazione | Tipo di mittente | Per segmento 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 stessa verifica
Come si avvia una verifica?
La risorsa create di Prelude accetta target e options.code_size su /v2/verification. L'endpoint create di Bird accetta to e options.code_length. Fornisci un identificatore dispatch frontend reale solo quando quell'integrazione Prelude è in uso.
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);
Costo di migrazione
Cosa deve cambiare prima del passaggio?
Fai un inventario dei metodi, delle decisioni di rischio, dei template, degli ID mittente e dei controlli legati alla transazione che la tua applicazione utilizza. La guida alla migrazione da Prelude mappa i campi supportati. Un percorso voce, RCS, Viber, Zalo o di autenticazione silenziosa su cui fai affidamento richiede un'alternativa esplicita prima di passare a Bird.
Instrada le nuove create verso il provider scelto e mantieni i check in sospeso con il provider che ha emesso il codice. Mappa gli eventi di callback, installa il verificatore di firma corrispondente e persisti i check riusciti. Testa i retry per timeout, i reinvii dell'utente, l'avanzamento di canale e le verifiche scadute prima del passaggio. Rivedi la policy su mittenti e messaggi di Bird rispetto al flusso esposto al destinatario.
Cosa verificare prima di scegliere?
Bird è un'alternativa a Prelude per SMS ed email?
Un retry avvia una nuova verifica Prelude?
Posso modificare il limite di fallback di Prelude a ogni retry?
Cosa conservare dopo un check riuscito?
Mettilo in pratica.
Prosegui con la documentazione, le guide e gli esempi per questo argomento. Le risorse sono in inglese.
Prossimi passi
Inizia dalla guida alla migrazione, poi confronta i canali supportati e le unità di fatturazione.
Integra la verifica nel tuo prodotto.
Discuti con il nostro team i tuoi canali, il flusso di verifica e il traffico previsto.