Bird vs Prelude
Bird vs Prelude for Verify
Bird Verify exposes recipient-based delivery and code checks: create a code, advance the available channel plan and check the answer using the same recipient. Compare that flow with Prelude’s verification window and risk outcomes before moving a signup or login.
Trusted every day by teams that
build world-class software.
Which verification flow fits your application?
When Prelude fits
Prelude’s create response distinguishes success, retry, challenged, blocked and shadow_blocked. Its signals feed fraud decisions; challenged and shadow_blocked require account enablement. Keep or replace the risk decision your application relies on before moving its code delivery.
Prelude documents RCS, Viber, Zalo and silent network authentication alongside SMS, WhatsApp and Telegram; its request method also accepts voice. Bird’s selectable plan includes SMS, WhatsApp, email and Telegram. Voice is still rolling out and is not a customer migration option today. Retain or redesign a relied-on RCS, Viber, Zalo or silent-authentication method.
Prelude’s request options include templates, locale and an enabled sender ID. Custom codes, an explicit channel list, force_challenge and max_auto_fallbacks require account enablement. Those settings need an explicit migration decision, not a field rename.
Why choose Bird Verify?
Bird identifies the verification by the recipient, including an email address, phone number or both. Its country plan determines which channels are available; options.channels can trim or reorder that plan.
Bird’s check response returns success, reason and attempts_remaining. Store success: true in your application; a later check of a finalized verification returns 404 and does not undo that outcome.
Bird’s hosted MCP server and CLI examples run create, check and next-channel operations. An agent can request the next delivery channel with the same recipient its application already holds.
The matrix
How do the Verify APIs compare?
Compare recipient state, recovery and risk decisions. Channel availability and advanced options depend on destination and account enablement.
| Capability | Bird | Prelude | Who wins? |
|---|---|---|---|
| Create request | JSON with a bearer key to /v1/verify/verifications, with to.email, to.phone_number or both. | JSON create-or-retry with a bearer key and target.type plus target.value. Email verification requires contacting Prelude about the use case. | |
| Safe retries | Idempotency-Key replays the request. Recipient resends reuse the live verification, respect its cooldown and send a fresh code after it. | Repeating the request within a live verification window creates a retry attempt. The lifecycle guide documents minimum retry spacing and attempt limits. | |
| What a failed check tells you | success: false, reason and attempts_remaining. Persist a successful result before the verification is finalized. | Check status includes success, failure and expired_or_not_found. Transaction-bound codes can also return transaction_missing or transaction_mismatch. | |
| Channels a passcode can arrive on | SMS, WhatsApp, email and Telegram, restricted to the recipient’s resolved country plan. Voice is still rolling out and is not available for customer traffic. | Messaging channels include SMS, RCS, WhatsApp, Telegram, Viber and Zalo, plus silent authentication; method: voice requests a phone call. Availability depends on account and destination. | |
| Delivery events | Workspace subscriptions distinguish verification and delivery events; Standard Webhooks signatures authenticate the payload. | options.callback_url selects the destination per request. Generate a signing key to enable RSASSA-PSS SHA-256 signatures in X-Webhook-Signature. | |
| Fallback control | Delivery failure advances the resolved plan. Next-channel advances it on request and sends a fresh code; earlier codes remain valid. | max_auto_fallbacks limits additional automatic attempts and requires account enablement. It is fixed at creation; a requested retry gets a fresh allowance of that same limit. | |
| Hosted MCP server | Authenticated hosted MCP runs create, check and next-channel; the bird CLI exposes the same operations. | Prelude’s backend SDKs let application code call Verify. Its Node SDK exposes verification.create and verification.check. | |
| Code length | options.code_length chooses the code length; otherwise the workspace setting applies. | options.code_size accepts 4 to 8 digits and otherwise uses the dashboard setting. | |
| Risk outcome | Recipient send caps, check limits and country configuration. The create response returns a verification, without Prelude’s challenged or shadow_blocked outcome. | Create status and risk data support branching on blocked traffic. reason describes a block; risk_factors appears for blocked or shadow_blocked decisions when specific risk signals are detected; those fields are not a rationale for every successful send. |
Who controls the next delivery attempt?
Bird resolves its channel plan from the recipient and country. A delivery failure or explicit next-channel request advances that plan. Each explicit call moves forward at most one channel and sends a fresh code; earlier codes stay valid for the live verification.
Bird: create with to → resolved channel plan → failed delivery or next-channel → fresh code → check with the same to. An exhausted plan returns NoNextChannel. Record success before offering another send.
Prelude: create with target and signals → risk outcome → verification window → delivery route → automatic or requested retry → code check. Its lifecycle guide treats another create for the same number inside the live window as a retry, not a new verification.
Prelude’s fallback limit counts additional automatic attempts. A zero value disables automatic provider and channel retries. The value requires enablement and is fixed at creation; changing it on a retry is ignored, while a requested retry receives a fresh allowance of the fixed limit.
What does success mean in each response?
Bird’s check endpoint returns success: true when the code is accepted. HTTP 200 can also carry success: false and a failure reason. Keep the successful application outcome; a finalized-record 404 is not a reversal of authentication.
Prelude’s create status: success means a new verification window was created. Its check status: success is the result to use for code acceptance. Do not grant access from the create result. Both calls identify the target by its type and value.
Prelude’s check reference also defines transaction_missing and transaction_mismatch for prelude:psd2 codes. Preserve that transaction binding or choose an explicit replacement before migrating such a flow.
Which risk signals and webhook checks must survive migration?
Prelude defines dispatch_id as “The identifier of the dispatch that came from the front-end SDK.” in its create reference. Supply the SDK’s actual dispatch value when using that integration; an application-generated request UUID is not a substitute.
Prelude’s fraud guide describes server-provided signals and additional device signals from its frontend SDKs. Its challenged and shadow_blocked states require account enablement. Inventory the application branches that consume those results.
Bird’s send and check caps bound API use. They do not replace a risk verdict your signup flow depends on. Keep the application’s fraud decision around code delivery.
Prelude signs webhook payloads with RSASSA-PSS and SHA-256 after a signing key is generated in its dashboard. Bird uses Standard Webhooks. Keep signature verification, but replace the verifier and event mapping rather than reusing Prelude’s header logic.
How are verification and delivery billed?
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
| Published item | Prelude | Bird billing policy |
|---|---|---|
| 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. Channel sends are billed separately. Check the live channel rates below. |
| 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. Channel sends are billed separately. Check the live channel rates below. |
| Enterprise Custom volume | Contact sales Contact sales for committed volume pricing. as published | There's no plan, seat, or platform fee for Bird Verify. Channel sends are billed separately. Check the live channel rates below. |
| 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. Channel sends are billed separately. Check the live channel rates below. |
| 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. Channel sends are billed separately. Check the live channel rates below. |
| 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. Channel sends are billed separately. Check the live channel rates below. 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. Channel sends are billed separately. Check the live channel rates below. |
| 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. Channel sends are billed separately. Check the live channel rates below. This method is outside Bird’s documented Verify channel plan. |
Bird published SMS channel rates
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 | Sender type | Per SMS segment |
|---|---|---|
| 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.
The same verification
How do you start a verification?
Prelude’s create resource accepts target and options.code_size at /v2/verification. Bird’s create endpoint accepts to and options.code_length. Supply a real frontend dispatch identifier only when that Prelude integration is in use.
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);
Switching cost
What must change before cutover?
Inventory the methods, risk decisions, templates, sender IDs and transaction-bound checks your application uses. The Prelude migration guide maps supported fields. A relied-on voice, RCS, Viber, Zalo or silent-authentication path needs an explicit alternative before it moves to Bird.
Route new creates to the chosen provider and keep pending checks with the provider that issued the code. Map callback events, install the matching signature verifier and persist successful checks. Test timeout retries, user resends, channel advancement and expired verifications before cutover. Review Bird’s sender and message policy with the recipient-facing flow.
What should you check before choosing?
Is Bird a Prelude alternative for SMS and email?
Does a retry start a new Prelude verification?
Can I adjust Prelude’s fallback limit on each retry?
What should I store after a successful check?
Put it into practice.
Continue with the documentation, guides and examples for this topic. Resources are in English.
Where to go next
Start with the migration guide, then compare supported channels and billing units.
Make verification part of your product.
Talk through your channels, verification flow, and expected traffic with our team.