Twilio Changelog

Twilio sells Call per second (CPS) which allows customers to increase the rate at which Twilio will execute new calls created via the Calls API. CPS is sold and billed in us1 and the CPS value is replicated to other Regions (e.g. au1/ie1) at no additional cost to allow customers to operate across all timezones. The replication of the CPS value also allows services to fallback to a different Region in the event that a Region becomes unavailable. Twilio has updated the Acceptable Use Policy regarding concurrent utilization of CPS across Regions; specifically persistent maximum utilization of CPS in multiple Regions concurrently is prohibited. For more information, see the Programmable Voice: No Concurrent Voice Calls per Second in Multiple Home Regions section of the AUP.

Twilio has completed validation of the integration between Flex and Lionbridge Language Cloud real-time language translation solution. Using a database of over 110 languages, this integration enables your agents to send SMS, Chat or WhatsApp messages in their native languages, and have customers read them and send return messages in their native languages.

To learn more about Lionbridge capabilities and how to enable it for your application, visit our integration documentation.

As previously communicated, the 2008 version of our Programmable Voice API has reached end-of-life and requests made to 2008 endpoints or resources will not receive responses. We have discovered a small subset of requests to 2008 resources that were not entirely shut down during the previously communicated end-of-life timeframe. Starting May 2, 2022 all requests to any 2008 Voice endpoint will receive a 404 response from Twilio.

As per Internet Engineering Task Force (IETF) recommendations, Twilio strongly recommends the use of TLS version 1.2, and has deprecated default support for TLSv1.0 and TLS v1.1 when connecting your SIP Infrastructure to Twilio Programmable Voice. If your infrastructure requires TLSv1.0 or TLSv1.1, you can configure your Twilio Account to allow these deprecated versions in your console under Voice → Settings → Allow Deprecated SIP/TLS versions.

In order to reduce service disruptions for existing customers, we have already applied this configuration to existing accounts that have used or provisioned SIP Domains and/or Elastic SIP Trunks. You can review the setting in your Twilio console, and disable the configuration, if your SIP server is already using TLSv1.2. New accounts will not have this configuration applied, meaning that these accounts will be configured to use only TLSv1.2 by default. The ability to “Allow Deprecated SIP/TLS Versions” is available to these accounts, but if so, this configuration needs to be enabled in the account’s console.

For more information, see our documentation.

Video Insights brings self-service tooling to the Twilio Console to help you observe application usage and quality, discover trends across all your rooms and participants, and troubleshoot end-user issues. You can use Video Insights to build higher-quality video experiences for your customers, reduce churn, and scale confidently.

As part of the general availability launch, you will now have a revamped experience to filter and explore your rooms, dropdowns for segmenting your participants by signaling_region and end_reason via the Insights Dashboard, and much more.

Get started now by visiting Video Insights in the Twilio Console or refer to our blog post to learn more.

As per Internet Engineering Task Force (IETF) recommendations, Twilio strongly recommends the use of TLS version 1.2, and has deprecated default support for TLSv1.0 and TLS v1.1 when connecting your SIP Infrastructure to Twilio Elastic SIP Trunking. If your infrastructure requires TLSv1.0 or TLSv1.1, you can configure your Twilio Account to allow these deprecated versions in your console under Voice → Settings → Allow Deprecated SIP/TLS versions.

In order to reduce service disruptions for existing customers, we have already applied this configuration to existing accounts that have used or provisioned SIP Domains and/or Elastic SIP Trunks. You can review the setting in your Twilio console, and disable the configuration, if your SIP server is already using TLSv1.2. New accounts will not have this configuration applied, meaning that these accounts will be configured to use only TLSv1.2 by default. The ability to “Allow Deprecated SIP/TLS Versions” is available to these accounts, but if so, this configuration needs to be enabled in the account’s console.

For more information, see our documentation.

When users message a business from a "Click to WhatsApp" advertisement, Twilio will now pass additional information to inbound message webhook regarding the advertisement the user clicked on. This allows businesses to create workflows in WhatsApp that intelligently respond based on the originating advertisement. Businesses can also better understand their advertisement’s performance by tracking user responses to an advertisement.

To learn more about the new properties that are included on our request to your webhook, visit https://www.twilio.com/docs/messaging/guides/webhook-request#whatsapp-specific-parameters.

The Generic Pay Connector is now available in Public Beta. The Generic Pay Connector is responsible for collecting sensitive payment information in a PCI compliant manner and passing it downstream to the payment processor of your choice - configured by you within the connector.

This connector supports 2 transaction types: charge and tokenization. The API provides flexibility to the payment processors to define the nature of the transaction taking place.

With the release to Public Beta, a new generic endpoint “/” is available and the transaction type is now a method within the generic endpoint. With that, legacy endpoints - “/charge” and “/tokenize” available in the Generic Pay Connector are going to be deprecated in the next 30 days. Applications using legacy endpoints in private beta would need to be modified to consume from the root endpoint “/”.

With this release, there is also support for passing custom parameters in the request to the payment processor. These features are supported for both <Pay> verb and Agent Assisted Pay.

Learn more about this feature in our API docs.

To simplify your console experience and eliminate redundancy, the SIP Trunking Call Log page has been removed as of 3/28/2022. All information for SIP Trunking Calls can be found on the Call Log page.

Twilio SendGrid's SAML-based Single Sign-On (SSO) is now generally available with support for just-in-time (JIT) provisioning, multiple Subuser access, and dedicated integration guides for the Okta and Azure Active Directory identity providers (IdP)s.

Twilio SendGrid SSO integration allows you to securely and centrally control access to your SendGrid account and streamline password management with your IdP of choice.

With the latest release of Twilio SendGrid SSO, you can now:

• Automatically provision users with JIT support, reducing the time you spend adding users to the Twilio SendGrid application.
• Assign multiple Subusers to a single SSO teammate, improving access flexibility while still restricting the scope of their actions.
• More easily integrate SSO with dedicated guides for the Okta and Azure IdPs — official integrations for both IdPs will soon follow.