Migrate Verify from Prelude

This page maps Prelude's v2 verification API to Bird Verify. Follow the main migration guide in order and use these mappings for steps 1 and 3.

The shapes are close. Prelude's POST https://api.prelude.dev/v2/verification and POST /v2/verification/check are a bearer-authenticated create-and-check pair keyed by the target rather than by a verification ID, and so are POST /v1/verify/verifications and POST /v1/verify/verifications/check. Calling create again for a live recipient retries rather than starting a new verification on both platforms. What does not port is the risk layer: Prelude's signals, routing verdicts, and silent verification have no counterpart in the Bird Verify API.

The channel sets overlap only partly. Bird delivers over email, SMS, WhatsApp, and Telegram; Prelude's RCS, Viber, Zalo, voice, and silent channels have no Bird equivalent today. A number that Prelude reached over Viber or Zalo falls back to SMS here, which is a delivery-rate question worth measuring in the pilot rather than discovering at full volume.

Both check endpoints take the recipient and the code with no verification ID, so this call ports almost as it stands. The response is where they differ:

Prelude folds "wrong code" and "out of attempts" into failure; Bird separates them, and returns attempts_remaining alongside so you can show the user how many tries are left. A verification that has already resolved returns 404 rather than a status, so store the first definitive answer instead of re-checking.

Prelude's create response reports a routing verdict: a status of success, retry, challenged, blocked, or shadow_blocked, with a reason and risk_factors when it refuses, and a method naming the channel it chose. Bird's create response is the verification itself. There is no verdict to branch on, no signals object to send, and no equivalent of a shadow block, so an integration that gates sign-ups on Prelude's verdict needs its own decision before it calls Bird.

What Bird does carry from that space is narrower and mostly configuration: per-country enablement to shut off destinations you never serve, the platform send and check caps described in Abuse guardrails, and the channel plan itself. If pumping protection was the reason you chose Prelude, size that gap before scheduling the move.

Prelude posts delivery status to the callback_url you set per verification. Bird delivers to endpoints your workspace registers, each subscribed to the event types it wants, so the URL leaves the request body. Subscribe to verify.verification.* for the session and verify.attempt.* for each passcode send, and verify signatures per Standard Webhooks. The payloads are in Verify events.

The cutover rule in the main guide applies unchanged: a code Prelude issued cannot be checked by Bird, so switch at the create call and route each check to whichever provider issued that verification until the last one expires. Because both APIs key on the recipient, the branch is a single conditional around your existing call sites rather than a rewrite.

Watch conversion during the pilot alongside delivery. Prelude routes per request across a wider channel set; Bird routes on the channel order you set per country. If a market's conversion drops, reorder that country's channels before concluding anything about the port.