Product changelog and announcements

You can now specify the SMS or MMS sender Twilio uses when an RCS message fails to deliver using the new "FallbackFrom" parameter in your /Messages API request. The FallbackFrom sender must be in the same account SID, but does not need to be in your Messaging Service's sender pool.

This can be useful if you need fallback messages to come from a specific number, instead of relying on Twilio's automatic selection. You can also use this to send from one RCS sender representing your brand, with different fallback numbers per department, store, or representative.

For more information, please see our docs.

The Country Code Geomatch feature within Messaging Services now supports RCS in a public beta. If you have distinct RCS senders approved per country, you can add each of them to the sender pool of a single Messaging Service. When you send from that Messaging Service, Twilio will select the RCS sender that matches the country of your recipient’s phone number.

Previously, each Messaging Service supported only one RCS sender, which meant customers sending to recipients in multiple countries had to maintain separate Messaging Services and build their own routing logic. RCS Geomatch removes that requirement.

For more information, see the Messaging Services’ docs.

Twilio ConversationRelay now supports Payment Card Industry (PCI) compliant Voice workflows when configured with PCI-compliant TTS (text-to-speech) and STT (speech-to-text) providers. Please refer to Twilio's Responsibility Matrix to see a list of PCI-compliant TTS/STT vendors and for further information. To learn more about ConversationRelay please see the docs.

Twilio Programmable Messaging now supports adding AT&T test numbers to your RCS sender.

You can now prototype and test your RCS sender on all major US carriers.

Once you’re ready to use RCS for production traffic, submit your RCS compliance information and our operations team will guide you through the carrier approval process

Go to Console to get started now.

For more information, see our docs.

Twilio Communications APIs now support OAuth 2.0. Upgrading to OAuth 2.0 makes your applications more secure than using traditional API keys or Auth tokens. Here is why:

• Short-lived tokens: OAuth 2.0 generates short-lived access tokens instead of static, long-lasting credentials.
• Scoped access: Each token only works with the specific APIs it was issued for, so a compromised token doesn't expose everything.

Starting June 30, 2026, PrivacyPolicyUrl and TermsAndConditionsUrl will be required fields when registering a new A2P 10DLC campaign via the Twilio Messaging REST API. Campaign creation requests that don’t include both fields will be rejected during campaign review.

Branded Calling Insights for Canada, the United Kingdom, and Germany are now live in the US1 region.

V2 of Verify Message Status events is now available. This version adds a "tags" parameter to the event stream. By including key-value pairs in your Start New Verification request, you can now pass custom metadata through to your stream for better tracking. Check out the Message Status Stream guide to get started.

New customers subscribing to the Verification Event stream will no longer provide updates on the delivery_status for each send_code_attempt and its value will be set to a static status of SENT. The error_code attribute will also be removed from each attempt. To obtain updates on message delivery status, new subscribers should now use the new Message Status Event Stream.

Verify Event's Verification stream has a new version 3 that includes a new "tags" parameter in each attempt. This set of custom tags will appear in the event stream when you include a key value pair in the tags parameter of the Start New Verification request. To learn more, please visit our Verification Status Stream guide.