Twilio Messaging Updates & Release Notes

Twilio Cohorts is now available in Private Beta, providing a set of APIs designed to handle list building, audience segmentation, and bulk execution natively within the Twilio platform. Set up your customer profiles, segment them, and trigger messages using your existing Twilio account.

Twilio Cohorts includes:

• Dynamic List Building & Segmentation: Define customer traits and query dynamic audiences directly within Twilio.
• Native High-Volume Delivery: Pass a single CohortID when triggering a send with the Twilio Email API or the Twilio Bulk Messaging API (supporting Email, SMS/MMS, RCS, and WhatsApp) without writing custom batching logic.
• Unified Execution: Streamline multi-channel workflows and eliminate custom queuing or backend rate-limiting logic.

Coordinating high-volume delivery across Email, SMS, RCS, and WhatsApp alongside your native Twilio data has never been easier.

To request early access to the Private Beta, submit a request form. For API details and technical guidance, see the Twilio Cohorts documentation. Twilio Cohorts documentation

You can now send RCS messages to Rogers phone numbers, completing RCS coverage across Canada’s major carriers.

When requesting RCS Sender approval in Canada, Twilio will now submit the Sender for review across all major carriers, including Rogers. RCS Senders already approved by other Canadian carriers will automatically be submitted to Rogers for review and approval. No action is required.

To start sending branded RCS messages, go to the Twilio Console to create and submit an RCS Sender.

For more information, see our RCS documentation.

To improve platform stability, endpoint reliability, and system performance, Twilio is introducing standardized rate limits for Content API requests.

Rate limits will be enforced at the account level. Requests exceeding these limits will receive an HTTP 429 Too Many Requests status code.

Rate Limits by Endpoint

Read Operations

• Fetch Content (GET /v1/Content/{Sid}): 100 RPS
• Fetch Approval (GET /v1/Approval/{Sid}): 100 RPS
• List Content (v1 & v2) (GET /v1/Content): 20 RPS
• List Content & Approvals (v1 & v2) (GET /v1/ContentAndApprovals): 20 RPS
• List Legacy Content (GET /v1/LegacyContent): 20 RPS

Write Operations

• Create Content (POST /v1/Content): 100 RPS
• Create Content Approval Request (POST /v1/Approval): 100 RPS
• Update Content (POST /v1/Content/{Sid}): 20 RPS
• Delete Content (DELETE /v1/Content/{Sid}): 100 RPS
• Update Content Approval Request (POST /v1/Approval/{Sid}): 20 RPS

What You Need to Do

• Implement Exponential Backoff: Ensure your application can handle HTTP 429 status codes by incorporating backoffs and retries.
• Audit High-Volume Pipelines: If your service executes bulk script operations (such as creating or deleting content templates in high-concurrency bursts), adjust your client throttling to remain within these thresholds.

We are excited to announce General Availability support for WhatsApp Embedded Signup Version 4. This release upgrades the existing WhatsApp Self Sign-Up onboarding flow in the Twilio Console, seamlessly aligning with WhatsApp’s recent account updates to deliver a cohesive, up-to-date sender registration process. The upgraded experience simplifies phone number setup and incorporates MM API Terms of Service acceptance directly within the flow. This update is required as part of WhatsApp’s planned deprecation of older versions, ensuring uninterrupted onboarding for WhatsApp senders.

Customers can now use the Consent Management API to programmatically re-opt-in users on US and Canada Toll-Free numbers.

Previously, opt-outs on US/CA Toll free numbers were strictly enforced at the network level, meaning an opt out block could only be lifted if the user texted an opt-in keyword like "START". Now, if a user provides valid re-opt-in consent outside of a messaging channel (e.g., via a web form, email, or in-app preference center), you can log their updated consent directly through the Consent Management API. Twilio will automatically pass this signal to downstream networks to clear the opt-out block and resume messaging.

Key Highlights

• Programmatic Re-Opt-In: Seamlessly restore message deliverability for users who re-consent via external channels.
• Fewer Failed Sends: Eliminate 21610 (Unsubscribed Recipient) and 30004 (Message Blocked) error codes for users who have re-consented to receive messages.
• Centralized Compliance: Keep your Twilio messaging traffic perfectly synced with your CRM and internal omnichannel engagement and consent workflows.

For more information, see our Consent Management API docs.

Learn more

Edit: As of August 10, 2026, the following change was completed. RCS messages which cannot be confirmed to be delivered will have an error code of 30046.

Starting August 10, 2026, the error code returned when an RCS message cannot be delivered to an unreachable end-user device will change from 30036 to 30046.

Error code 30046 (Message delivery not confirmed)

Error code 30046 (Message delivery not confirmed) gives developers a more accurate signal when an RCS message cannot reach an end-user device. Previously, 30036 (Validity Period Expired) was returned for these failures, pointing to queue and throughput settings as likely causes and making it easy to investigate in the wrong direction.

With 30046, the failure is correctly attributed to device-side conditions like the recipient's device being switched off, out of coverage, having no internet connection, or being unable to accept the message. This code will also serve as the standard for device-unreachable conditions across RCS and future OTT channels.

WhatsApp Usernames is now supported on the Twilio Platform and Messaging APIs for WhatsApp.

WhatsApp now allows users to adopt usernames. A username can optionally mask a user's personal phone number and allows them to interact with businesses through Business Scoped User IDs (BSUID). Twilio exposes this identifier in message webhooks and in Event Streams event data. Meta is releasing this functionality in multiple waves, starting on July 7, with additional countries to follow at later dates. Please check our documentation for the latest rollout schedule.

Twilio recently made improvements to our platform to increase RCS delivery and improve fallback consistency.

The time for a recipient’s device to confirm delivery before an RCS message’s status is updated to "undelivered" or a fallback SMS / MMS is sent, no longer depends on how long a message is queued within Twilio. Consequently, when messages queue within Twilio (as expected when sending large marketing campaigns) Twilio’s native fallback-to-SMS feature now ensures messages to RCS-capable devices are always attempted to be delivered on RCS, and no longer will fall back prematurely.

In addition, to optimize our platform by balancing successful RCS delivery with timely message resolution (whether that results in a native SMS / MMS fallback or a timely "undelivered" status), the amount of time given to devices to confirm delivery has been updated. As a result, you may notice messages falling back to SMS / MMS or an RCS message’s status updating to undelivered faster or slower than before.

No code changes are needed to take advantage of these optimizations. However, you may guide this behavior by ensuring you are using the "ValidityPeriod" parameter. Though the "ValidityPeriod" parameter continues to only apply to messages queued within Twilio’s platform, it is used to inform Twilio of how time-sensitive the message is and when a faster fallback or failure signal is needed. For time-sensitive messages, like OTPs or appointment reminders, it’s recommended to use a shorter value than the 10-hour default, like 30 seconds or 15 minutes. For customers sending RCS without Twilio's native fallback feature, these optimizations also ensure the message’s status moves to "undelivered" when it is no longer likely to be delivered, rather than waiting hours (or days) for it to inevitably expire.

Consent Management API is now Generally Available allowing you to programmatically sync, store, update, and manage user consent preferences globally across RCS, SMS, and MMS channels.

As of June 30, 2026, Consent Management APIs can now support healthcare use cases that may contain protected health information (PHI) for organizations that are subject to the Health Insurance Portability and Accountability Act (HIPAA). Twilio will sign Business Associate Addendums (BAA) with covered entities and business associates for HIPAA Eligible Services. Learn more about how to build on Twilio for HIPAA compliance.

Learn more about this feature and how to enable it in our documentation.