Changelog

Recently shipped.

Page 3

feature

Verify: choose which sender your passcodes arrive from

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.

feature

Numbers: buy and manage phone numbers over the API

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.

feature

SMS: configure what a reply to your numbers does

Keyword configuration is now open to every workspace, and on the public API alongside it.

Bird has always recognised and honoured a STOP on your numbers with no setup on your side, and that has not changed. What is new is that you can see exactly which keywords it recognises where, and make the replies say your name instead of ours.

Getting started

What's available

  • See what applies: list the rules for a country, or for one of your numbers in the order they are applied, including what a sender messaging from elsewhere gets.
  • Replace a reply: override Bird's opt-out, opt-in, or help wording for a country. Your rule keeps Bird's keywords unless you add more, including keywords Bird adds later, so your compliance answer does not go stale.
  • Campaign keywords: add custom keywords of your own with the reply you write.
  • Answer from your own system: switch Bird's auto-reply off for a rule while the opt-out itself keeps being honoured.
  • Everywhere you build: the dashboard, the API, the Go, TypeScript, Python, and PHP SDKs, bird sms keyword-rules on the CLI, and the matching MCP tools.

What an opt-out or opt-in keyword does is fixed and cannot be reassigned. Coverage is per country: listing the rules for a country shows what is recognised there, and where nothing is, no keyword is matched and no opt-out is recorded, so you are responsible for honouring opt-outs there yourself.

feature

SMS: statistics and suppressions on the public API

Two parts of SMS that were dashboard-only are now on the public API, with typed SDK methods, bird CLI commands, and MCP tools for each.

Getting started

What's available

  • Statistics: the aggregate summary, the daily and hourly series, and breakdowns by destination country, carrier, originator, category, status, and failure reason, plus counts of what your numbers received, by country, operator, and number. The same aggregation the Metrics dashboard reads.
  • Suppressions: list who your senders may not message and why, check one subscriber before sending to them, and add or end a suppression of your own. A send to a suppressed pair is refused with SMSRecipientSuppressed rather than going out.
  • Message timeline: a message's lifecycle events are now a public read, alongside the message itself.
  • Everywhere you build: the API, the Go, TypeScript, Python, and PHP SDKs, bird sms stats, bird sms suppressions, and bird sms list-events on the CLI, and the matching MCP tools.

improvement

SIP trunk TCP now works on port 5060

You can now send SIP over TCP to port 5060, the same port UDP already uses. TCP used to have a port of its own, 5062, which meant every TCP setup had to be told about it explicitly.

Nothing breaks if you are already on 5062: it still accepts TCP calls, so equipment pointed at it keeps working and needs no change. Use 5060 for anything you set up from now on.

TLS is unchanged on 5061.

For current setup, see the SIP trunk transport and connection settings.

Your next idea.
Ready to connect.