Verify API 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.

The check returns 200 with a result: invalid while attempts remain, then failed once they're exhausted, or expired once the window passes. A wrong code is a normal outcome you branch on, not an HTTP error.

Codes are generated with a cryptographic random source and stored only as an HMAC-SHA256 hash, compared in constant time. The plaintext code is never returned and never written to your stack or our logs. Length (4–10 digits), TTL, and attempt limits are configurable.

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

Authifly, Bird's verification brand. It's the identity on every code your users receive: email arrives from otp@verify.authifly.com or your own verified domain, and SMS and WhatsApp are Authifly-branded. authifly.com is a public page that reassures recipients Authifly sends legitimate one-time codes on a business's behalf. Bird is the platform you build on; Authifly is what the recipient sees.

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.

No. Bird checks by recipient: you send the phone number and the code, and we resolve the live session from the configuration-and-number pair. The configuration id is a constant; nothing is stored per verification.

SMS sends on the shared Authifly sender, which is deliverable in the countries where it's registered. Sender-ID rules are country-specific, and 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 the shared Authifly sender (otp@verify.authifly.com) by default, and you can override to a domain you've already verified for sending with Bird, so the code arrives from your brand.

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.

Codes are generated with a cryptographic random source and stored only as an HMAC-SHA256 hash, compared in constant time. The plaintext is never returned or logged.

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.

Two-factor authentication uses exactly two factors: typically a password plus a one-time code. Multi-factor authentication is the general term for two or more. Bird Verify provides the code-based factor for either.

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.

It's how a verification's settings resolve: per-request options, then your per-country overrides, then your configuration defaults, then Bird's per-country base. The highest tier that sets a value wins, and anything you leave unset falls through to the tier below, so you only configure what you want to change.

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 rather than rediscovering it.

No. It merges. You set the fields that differ for that country and the rest still inherits from your configuration and Bird's base, so an override is a small, targeted change rather than a full re-specification.

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.

Only as an HMAC-SHA256 hash. Bird generates the code with a cryptographic random source, sends it, and keeps the hash to compare against: the plaintext is never returned by the API or written to 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.

Per-recipient send caps bound the spend today. Dedicated fraud scoring and SMS-pumping protection are coming next, building on the per-send history Verify already records.

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.

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.