Recently shipped.

The Bird app is now listed in Zapier's directory, so a Zap can send over Bird's channels and read Bird's records without an HTTP block and without an API key. Search for Bird in the Zap editor, click Connect, and give consent in Bird. The connection is OAuth, and what Bird mints is owned by the workspace rather than by the person who clicked, so it keeps working after they change teams. Nothing asks you which region you are in either: the access token carries it.

Actions

Send Email, Send SMS, and Send WhatsApp Message cover the channels, template or free-form. Start Verification and Check Verification Code run a one-time passcode end to end, so a Zap can send the code and confirm the one the recipient types back.

The trigger

New Event starts a Zap from any of the 53 public Bird webhook event types: an email delivered or bounced, an inbound SMS, a WhatsApp send that failed, a sending domain that finished verifying. Pick the events you care about and Zapier registers the webhook endpoint for you. Every delivery is signature-checked before your Zap sees it, and one that fails the check is refused.

One limit is worth knowing before you build on it: a single Zap per organization can use New Event today. Zapier issues each Zap its own target URL, and Bird's webhook endpoint quota starts at one per organization, so a second Zap on this trigger comes back with WebhookTooManyEndpoints (as does the first, if you already run a webhook of your own). Support can raise that quota for your organization. Actions and searches are unaffected.

Searches

43 search steps read the records back: email messages, their events, recipients, stored content and attachments; inbound email down to the raw MIME; SMS messages, events, templates, keyword rules and suppressions; WhatsApp messages, events and media; voice calls; sending domains and their events; SMTP configurations; webhook endpoints and their delivery attempts. Email and SMS statistics get one search each, returning counts and rates rather than per-message records.

A search that matches nothing returns no results instead of failing the run, so a Zap takes its own no-match path rather than erroring out.

Managing the connection

Every connection shows up on the Integrations page in your Bird workspace, with the scopes it was granted. Revoking it there stops every Zap built on it.

Find Bird in Zapier's directory and build the first Zap.

The messaging preference store is now a public API. Preferences are stated consent grants and opt-outs, keyed by channel and handle (an email address or phone number), and they already decide delivery for every send: an opt-out blocks marketing traffic, and one recorded for all messages blocks transactional traffic too.

What's new

• GET/POST /v1/preferences and GET/DELETE /v1/preferences/{preference_id} are available to API keys carrying the new preferences scope. Recording a grant with consented_at evidence is also the documented way to resume mailing someone after an unsubscribe.
• The bird preferences CLI group and matching MCP tools cover the same operations, and all four SDKs gain a preferences resource with typed results.
• Four webhook event types are now public: preference.granted, preference.revoked, preference.deleted, and whatsapp_suppression.created. Each fires only when a statement actually changes a record.

Statements are ordered by when they were made rather than when they arrive, so an out-of-order write answers applied: false with the surviving statement instead of applying. A statement the recipient made themselves, such as an unsubscribe or a stop keyword, cannot be deleted through the API; it ends only when they opt back in.

Read more in the webhooks guide and the API reference.

Lookup answers questions about a recipient before you spend anything sending to them. Give it a phone number and it tells you what the number is: the network serving it, the country, whether it has moved network, and what kind of line it is. Give it an email address and it tells you whether the address will accept mail.

Both were reachable only with an API key on an allowlisted organization. They are now open to every workspace, in the dashboard and on the public API.

The problem it solves is spending on a recipient who was never reachable. A number that turns out to be a disconnected landline still costs a send attempt; an address with a typo in the domain costs a bounce and a small dent in your sending reputation. Checking first is a smaller cost than either.

What's new

• Two pages in the dashboard. Lookup checks one number or one address at a time and shows the whole answer, which is the fastest way to see what a lookup returns before writing any code. Reachable by any member whose role grants lookup access.
• The number lookup is a base answer plus properties you ask for. The base answer always runs and is always billed: country, serving network, issuing network, ported flag, coarse line type. Name classification, porting, presence, roaming, sim_swap or score in type to add more, and each is billed only when it is actually delivered. A property that could not be answered comes back with a status and costs nothing.
• The email lookup gives you one field to decide on. result is valid, neutral, risky, undeliverable or typo, with reason explaining an undeliverable verdict and did_you_mean carrying the correction for a typo. delivery_confidence runs 0–100 alongside it.
• Typed in every SDK, and on the CLI. lookup.phone_number and lookup.email are methods in the Go, TypeScript, Python and PHP SDKs, each with a worked example, plus bird lookup phone-number and bird lookup email.
• A retry cannot bill twice. Send an Idempotency-Key and a repeated request replays the stored answer instead of buying a second lookup.

An API key needs the lookup scope, and lookups draw on their own lookup rate-limit bucket rather than sharing your general write budget. Lookup overview explains what each request costs, and the phone number and email address guides cover every field.

Verify's Bird-managed sender is now a named choice between two identities, set per channel and per country. Bird Verify puts the Bird name in front of your users. Authifly is a standalone verification brand that names no platform vendor, so nothing about your delivery infrastructure is visible to the person receiving the code.

The choice reaches every channel that has a sender. On email it decides the from-address and the branding in the body. On SMS it decides the alphanumeric sender ID, in the countries that permit one. On WhatsApp it decides which Bird-managed business number the message comes from. Telegram is unaffected: its codes come from Telegram's own verified account, which is not ours to brand.

What changed for existing configurations

Nothing, if you had already sent a passcode. Every configuration that existed before this release was pinned to Authifly, which is what it was already sending as, so no recipient sees a different sender than they did last week.

Two cases did move to Bird Verify, because they had no stored sender to keep: a workspace with no Verify configuration at all, and a send in a workspace with several configurations that did not name which one to use. If either describes you and you want Authifly, select it on the Channels tab.

Using it

Open the Channels tab and pick an identity on the Email, SMS, or WhatsApp row. To override it for one destination, set a sender on that country in country configuration. A per-country choice wins over the channel default for recipients there.

Full detail, including what each channel shows in countries that require a short code or a local number: Senders and branding.

The numbers your workspace sends from are now yours to manage over the API. Search what is on sale in a country, order one, and release it when you are done, without opening the dashboard.

Buying a number was a dashboard task, which meant provisioning could not be part of anything automated: onboarding a customer onto their own number, or giving a new region its own local presence, ended at a form somebody had to fill in. These are the same operations the dashboard has been using, now published.

What's new

• Search, scoped to a country. GET /v1/numbers/available takes a country_code and narrows from there by type, capability, or a prefix of national digits. Bird's own stock pages normally; the last page can include what a carrier is offering live.
• Buying is an order you can follow. POST /v1/numbers/orders usually completes inside the request and hands back the number. One that has to wait on a carrier comes back still running, and GET /v1/numbers/orders/{order_id} polls it to completed or failed. Send an Idempotency-Key and a retry cannot buy twice.
• Read and release what is allocated to you. GET /v1/numbers lists your numbers with their type, capabilities, and status; DELETE /v1/numbers/{number_id} releases a dedicated one and stops its monthly charge.
• Typed in every SDK. numbers.available.list, numbers.orders.create, numbers.list and numbers.release are methods in the Go, TypeScript, Python, and PHP SDKs, each with a worked example.

An API key needs the new numbers scope, and the first purchase in an organization needs identity verification. Buy and release a number walks the whole flow, and Numbers overview explains what the fields on a number mean.