Recently shipped.

Agent Mailboxes give your AI agents a durable email address they can own, read, and reply from. Every inbound message lands in a conversation thread with parsed body text and attachment metadata; your agent reads it and replies in one API call. No mail server to run, no domain to verify.

Claim an address. Omit the local part and Bird generates a unique address (abc123@inbox.ai) at no extra cost. On paid plans you can choose your own handle (support@inbox.ai) up to your plan's allowance, or use your own inbound-enabled domain. Each mailbox has a receive policy (open, replies_only, allowlist, drop), per-sender allow/block rules, and a 30-day retention window.

Read conversations. Inbound mail groups into threads automatically. Each message carries quote-stripped extracted_text — the new content only, without the history your agent would otherwise have to parse. Threads have placement labels (inbox, archive, spam, blocked, plus any custom label), unread state, and a last_direction field so your agent always knows whether the last move was theirs.

Reply and compose. Reply to a message in one call — the reply folds into the existing thread and sends from the mailbox address. To start a fresh outbound conversation, compose from the mailbox; the response carries a thread ID for tracking replies.

Webhooks. Subscribe to email_mailbox.message_received, email_mailbox.thread_created, email_mailbox.message_sent, email_mailbox.message_delivered, and email_mailbox.message_failed. Only inbox-placement mail fires webhooks — spam and blocked mail is stored silently.

Available on every surface

Surface	How to use
REST API	/v1/email/mailboxes + /v1/email/threads — new mailbox and mailbox_management API key scopes
TypeScript SDK	bird.mailbox, bird.mailboxThread, bird.mailboxThreadMessage
Python SDK	client.mailbox, client.mailbox_thread, client.mailbox_thread_message
Go SDK	client.Mailbox, client.MailboxThread, client.MailboxThreadMessage
CLI	bird email mailboxes · bird email threads · bird email threads messages
MCP	Full tool set — email_mailboxes_*, email_threads_*, email_threads_messages_*

Getting started

Create an API key in the dashboard — under the Email group, enable the mailbox scope, then follow the Agent Mailboxes quickstart to claim an address, receive your first message, and send a reply in under five minutes.

Full API reference, receive rules, retention, and webhook payloads: Agent Mailboxes guide.

You can now deliver one-time passcodes over WhatsApp, alongside SMS and email. WhatsApp OTPs are sent from the shared Bird Authifly sender — the same "Authifly" brand you already see on our shared email sender — using the built-in authentication template, so there's no template or sender setup required. Support for your own dedicated senders is following shortly.

What's new

• Enable WhatsApp per country from the Verify → Countries settings in the dashboard.
• Automatic failover: if the primary channel can't deliver, Verify falls back through your configured channels before giving up.
• API & SDK: whatsapp is now a valid value for a verification's channel, and country routes accept a whatsapp key in their per-channel settings. This is additive — no breaking change.

Default routing change

Existing phone verifications now default to SMS → WhatsApp → email: SMS stays primary, with WhatsApp as an automatic fallback before email. Countries you've already customized are left untouched.

WhatsApp lifecycle events are no longer poll-only. Subscribe to any whatsapp.* event type from the dashboard's Webhooks page or with POST /v1/webhooks, and Bird pushes the same accepted, sent, delivered, read, and failed events you'd otherwise fetch from GET /v1/whatsapp/messages/{message_id}/events. Each delivery carries whatsapp_id, workspace_id, the message direction, from/to addresses (phone number and/or Meta business-scoped user ID), and the tags and metadata from the original send; failed messages include an error object with a Bird-stable failure code. See WhatsApp events.

Also in this release:

• Inbound email messages (get, list) now return an authentication field (pass, fail, or unknown) giving a single verdict on whether the sender's identity was verified, alongside the existing SPF/DKIM/DMARC flags.
• New guide: Plan changes & renewals spells out exactly when plan upgrades, downgrades, and cancellations take effect, and the day-by-day sequence for a failed renewal payment. It also documents that overage on paid plans is capped at 5x your plan's included email volume per period, with sends rejected past that ceiling until the period resets; the Free plan has no overage at all.

Bird Verify is now available to every workspace. Send a one-time passcode and confirm the code your user enters in two API calls — no sender to register, and no verification id to store.

Getting started

• Verify your first customer
• Verify overview
• Sending verifications

What's available

• Send and check: start a verification with POST /v1/verify/verifications — which also resends after the cooldown — then confirm the code with the check endpoint. A code can be checked once.
• Email and SMS with failover: pick the channels and their order; if the first channel can't deliver, Verify falls back to the next one on the same code budget.
• Per-country configuration: set channel availability and order, per-country senders, and a verified-domain email sender — a per-workspace overlay on Bird's per-country base.
• Built-in safety: code length and lifetime, maximum attempts, resend cooldown, and per-recipient and per-workspace rate limits, all configurable.
• Everywhere you build: the Verify API, the dashboard (onboarding, verifications log, countries, and configuration), the bird verify CLI, the Bird MCP server, and the Go, TypeScript, and Python SDKs.

More is on the way — WhatsApp and voice channels, dedicated senders, and customer-authored templates among them.

The WhatsApp Metrics page is out of "coming soon" and live in the dashboard at WhatsApp → Metrics. It's the aggregate view of your channel that the per-message message log can't give you: delivery rate and failure rate measured against fixed thresholds (95% and 5%), accepted volume, and cost, over the last 24 hours, 7, 30, or 90 days.

Below the summary tiles:

• A delivery-over-time chart of accepted, delivered, and failed volume, to spot spikes and bad sends.
• A failure-rate trend line plus a histogram of failures by Bird-normalized error code.
• Delivery latency, Bird's own processing time from accepting a message to handing it to the WhatsApp network, at p50/p95/p99.
• Breakdowns by sending number, template category, and tag, each with its own Healthy/Watching/Throttled status.

Alongside it, WhatsApp's rate limits are now documented: a dedicated whatsapp_send group (10/min base) for sending, kept separate from the shared list/read/write management limits so send quota is never eaten by management traffic.