Recently shipped.

Bird has an official PHP SDK. composer require messagebird/sdk gives you a typed client over the same curated surface the Go, TypeScript, and Python SDKs cover, so a PHP service no longer has to hand-roll HTTP calls against the API.

It targets PHP 8.2+ and is synchronous. Requests go through any PSR-18 client you already have, Guzzle or Symfony HttpClient included, discovered automatically. Nothing pins you to a transport, and per-request timeouts stay where you already configure them.

What you get

• The curated surface, method for method with the other SDKs: email (send, batch, get, list, cancel, stats, mailboxes, threads), SMS and its templates, WhatsApp, Verify, contacts, contact properties, audiences, domains, and realtime.
• A one-argument client. Only the API key is required. The region comes from the key's bk_{region}_ prefix, so a bk_eu1_… key routes to EU with no extra configuration.
• Retries and idempotency you don't write. Transient failures retry with jittered backoff and honor Retry-After, and every mutation, DELETE included, carries an idempotency key generated once and reused across attempts. A retry cannot act twice.
• Errors as exceptions. A failed call raises ApiException carrying the HTTP status plus the API's own error type and code, so you branch on a stable value instead of parsing a message.
• Webhook verification. $bird->webhooks->unwrap() checks a Standard Webhooks signature against your signing secret and hands back the verified payload.
• An escape hatch for the long tail. get, post, put, patch, and delete on the client reach any endpoint directly, so a newly shipped API operation never waits on an SDK release.

Not in this release

Framework packages. The quickstart is a plain PHP script, and there is no Laravel or Symfony integration yet. The client itself works inside either framework today; what is missing is the idiomatic wrapper, which is on the roadmap.

To send something, start with the PHP email quickstart. For the client's configuration, retry, and error model, see the PHP SDK reference.

When a user tells your app the passcode never arrived, you can now move them to another channel on demand. POST /v1/verify/verifications/next-channel advances a live verification to the next channel in its plan and sends a fresh code there, without waiting out the resend cooldown a second create would honour.

Until now the only way onto the next channel was to let Verify get there itself, after a send failed or a delivery report came back terminal. Neither helps the common case: the message was accepted, nothing came back to say otherwise, and the user is still staring at an empty inbox. This is the endpoint behind an "I didn't receive my code" button.

What's new

• One call, keyed by the recipient. Pass the same to you created the verification with, exactly as you do for a check. There is still no verification id to store.
• No cooldown, no lost codes. A deliberate channel switch sends immediately, and every code already sent stays valid, so a message that turns up late still verifies.
• The response tells you where it went. You get the verification back with last_channel naming the channel the new passcode was sent on.
• On every surface. The SDKs expose it as Verify.Verifications.NextChannel (Go), verify.verifications.nextChannel (TypeScript), and verify.verifications.next_channel (Python), the CLI as bird verify verifications next-channel, and the MCP server as the verify_verifications_next_channel tool.

A verification whose channel plan has no further channel answers 422 with NoNextChannel; fall back to calling create again to resend on the current channel. Send the code on another channel covers the flow and the rest of the error cases.

Bird's dashboard now has broadcasts. Pick a stored audience and a published email template, and Bird resolves the audience's current members into a recipient list at send time, so reaching everyone in it takes naming the audience rather than listing addresses yourself.

Getting started

• Broadcasts
• Audiences

What's available

• A three-step composer: pick the audience and sender in Recipients, the published template in Content, and the category, tracking, and tags in Review. Submitting only ever creates or saves a draft; sending is a separate, explicit step.
• Send now or schedule ahead: schedule up to 365 days out, and reschedule a scheduled broadcast right up until it starts sending.
• Per-broadcast delivery tracking: recipients, sent, delivered, bounced, complained, opens, and clicks on the broadcast's own detail page, plus a per-recipient timeline and event view.
• Clear failure reasons: a failed broadcast names why on its detail page, from an empty audience to a template that no longer renders, so you know what to fix before you resend.

Broadcasts is a dashboard feature today, with no public API, CLI, or SDK surface.

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.

Getting started

• Create an API key in the dashboard — under the Email group, enable the mailbox scope.
• Agent Mailboxes quickstart: claim an address, receive your first message, and send a reply in under five minutes.
• Agent Mailboxes guide: full API reference, receive rules, retention, and webhook payloads.

What's available

• Claim an address: omit the local part and Bird generates a unique address (abc123@inbox.ai) at no extra cost. On paid plans, choose your own handle (support@inbox.ai) 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

• 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_*.

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.