Verify FAQ

Two calls: create a verification for a recipient, then check the code they enter. The check is by recipient, so there's no verification id to store between the two: the configuration id (a constant) and the address are all you need.

Email, SMS, and WhatsApp today. Voice is rolling out as an additional channel, and the channel order, sender, and which channels are on are configurable per country, without a code change.

No. Re-sending is the same create call (create-or-retry), and checking is by the recipient address, so a verification needs no per-request state on your side. An id is returned if you want to read status later, but it's optional.

One of two Bird-managed identities, and you pick per channel: Bird Verify by default, or Authifly. Email arrives from otp@verify.bird.com, from Authifly's otp@verify.authifly.com, or from your own verified domain, and WhatsApp sends from that identity's business number. SMS shows the identity as its sender ID wherever a country permits a branded one, and a short code or local number where one is required. Authifly is the one to pick when you want no platform vendor visible to your users at all, and authifly.com is a public page that reassures recipients Authifly sends legitimate one-time codes on a business's behalf. Authifly is operated by Bird B.V.

Verify isn't on the public price list yet. Get in touch and we'll walk you through pricing for your channels and volume.

No. There's no Verify plan or platform fee. You pay the delivering channel's normal rate for each code sent, nothing more.

Nothing. Only sends bill; a check call, whether it succeeds or fails, is always free.

Yes, because two sends went out: the original delivery and the fallback delivery, each at its own channel's rate. A resend to the same channel works the same way.

Six numeric digits for ten minutes, out of the box. Both are configurable: 4 to 8 characters, and anything up to about 16 hours. Only numeric codes are issued today.

The check returns 200 with success: false and a reason: incorrect_code while attempts remain, attempts_exhausted once they're spent, or expired once the window passes. A wrong code is a normal outcome you branch on.

Five by default, and you can set anywhere from 1 to 10. Once the budget is spent the verification fails and that code is dead, so the user starts a new one.

There's a cooldown between sends to one recipient, 60 seconds by default and configurable up to an hour, plus a per-recipient hourly cap on how many codes can go out at all. Both exist to bound what a spammer or a pumping attack can cost you.

An SMS one-time passcode is a short code texted to a phone number that the user types back to prove they control that number. It's the most widely used second factor and signup check because almost every phone receives SMS.

SMS sends on a Bird-managed shared sender, Bird Verify or Authifly. Sender-ID rules are country-specific: some countries permit a branded sender ID, and others require a short code or a local number. Registered and dedicated senders extend reach over time.

Per-recipient send caps and a per-verification guess limit are built in today. Deeper fraud signals and SMS-pumping protection are coming next.

Email needs no phone number and reaches anyone with an inbox, which makes it a strong default for signup and account-recovery flows and a natural fallback when you don't have a verified phone number. Many products offer both and let the user choose.

Yes. Codes go from a Bird-managed shared sender by default (otp@verify.bird.com, or Authifly's otp@verify.authifly.com if you pick that identity), and you can override to a domain you've already verified for sending with Bird, so the code arrives from your own address.

OTP email is transactional system mail, so it isn't gated on the marketing suppression list. Delivery is handled asynchronously by the email pipeline, the same as any transactional send.

Yes. WhatsApp ships as a launch channel alongside email and SMS, an orderable entry in the per-country plan, with no change to the create or check calls. Voice is the channel still rolling out.

WhatsApp authentication-template messages are branded and arrive in an app many users already keep open. In markets with heavy WhatsApp use, ordering it ahead of SMS lets you meet people on the channel they prefer, with SMS still in reserve.

A phone target carries its whole phone-family channel plan, so SMS sits next in line behind WhatsApp. As delivery-driven advancement rolls out, a WhatsApp-first verification moves on to SMS in the same session, and every code in that session stays valid until it verifies, expires, or runs out of attempts.

It's rolling out. Email, SMS, and WhatsApp verification are available now; voice lands as an additional orderable channel in the same per-country plan, with no change to the create or check calls.

Voice reaches landlines and users who can't receive SMS, and it's a strong fallback when a text doesn't arrive. It's also the more accessible option for users who can't read a code on screen.

Both are phone-family channels addressed by the same number. Order them in the channel plan (commonly SMS first, voice as fallback), and a single verification can move from one to the other while every code in the session stays valid.

Use the address you already have: a phone number verifies over SMS or WhatsApp, an email address over email. Per-country configuration controls the order and senders per market.

No. Bird checks by recipient, so your login handler sends the code and later checks it by the same address: there's no verification id or pending-code record to keep on your side.

With two-factor, the code is a second proof on top of a password. Passwordless removes the password and uses the code as the only credential. Both are the same Bird Verify send-then-check flow: what changes is whether a password sits in front of it.

It removes the most-attacked credential: passwords get reused, phished, and breached. The one-time code is generated cryptographically, stored only as a hash, and guarded by attempt lockout and send caps, so possession of the channel is the factor.

That's where silent (carrier-network) authentication is headed: confirming the phone number through the mobile network with no code to enter. It's designed into the Verify model as a future channel, so adopting it later won't mean re-architecting your login.

A create call resolves against Bird's per-country base: the channel order, senders, and code and TTL defaults Bird maintains from running email and SMS at scale. Per-request options such as channels or code_length can reorder or narrow that plan for a single call, and anything left unset comes from the per-country base. Per-country availability and the global kill-switch then cap what can appear on the resolved plan, which comes back on every response.

A sensible starting point in every country without any setup: which channels are worth trying, which senders are allowed, and reasonable code defaults, maintained by Bird from years of running email and SMS. You build on top of it instead of rediscovering it.

No. Per-country availability is a ceiling, not a default: you can only enable what Bird supports there. Enabling an unavailable channel is a no-op rather than a silent failure, so a plan can never promise a channel that can't actually send.

From the recipient's E.164 phone number, at resolve time. You don't pass a country; Bird derives it and applies the matching route. Email is country-independent.

With a cryptographic random source, and stored only as an HMAC-SHA256 hash that is compared in constant time. The plaintext code is never returned by the API and never written to your stack or our logs.

Each session has a bounded number of checks (5 by default), and each one is compared in constant time so timing leaks nothing. Once the budget is spent the session fails, so an attacker can't keep guessing.

No. Cryptographic generation, hashed storage, constant-time checks, attempt lockout, and send caps are how every verification behaves: there's no security tier to buy.

In the region your organization is hosted in, either us1 or eu1. Your API key carries it in its prefix (bk_us1_…, bk_eu1_…), which is how the SDKs and the CLI pick the right endpoint without you configuring one.

Only what you scope it to. A key carries a list of scopes, each at read or write, so a key that creates verifications need not carry anything else. You can also pin a key to a set of CIDR ranges, and rotate it with a grace period (24 hours by default) so a roll needs no downtime.

Certifications and security documentation live in the Trust Center at trust.bird.com. The data processing agreement, privacy statement and acceptable use policy are published at bird.com/legal. For a vendor questionnaire, your Bird account team handles it.