Twilio Changelog

Voice can now be used on Twilio Frontline to develop compliant healthcare applications that 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 Products and Services.

Learn more about Voice in Twilio Frontline and how to build on Twilio for HIPAA compliance.

The new Usage by SIM tab added to Super SIM Insights displays a per-SIM breakdown of your Super SIM data usage. Each row in the table shows how much data a SIM downloaded or uploaded and the total amount. Because the rows are sorted by total amount, you can easily identify which of your Super SIMs have exchanged the most data over a specified time period. View the top entries in the table to quickly single out any outliers. Filter the results by Fleet, Country, or Network to further slice-and-dice your usage.

In addition, the rightmost column contains spending information for each record. This data allows you to better understand your per-device spend on Super SIM usage. You can draw various insights, such as which of your SIMs have incurred the highest costs. It is particularly helpful to decouple data consumption and monetary spend into separate entries because different networks charge different rates. As such, although one SIM might be consuming less data than the other, it could still have incurred higher costs if it were operating on a more expensive network.

Access Usage Insights by SIM in Console via Monitor > Insights > Super SIM and select the “Usage by SIM” tab.

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.