The delivery of an event via Event Streams is purely for informational purposes and is analogous to the informational webhooks Twilio supports today, described here. They are delivered in an asynchronous fashion and do not serve as a control plane for Twilio products. This approach differs from the one used by our TwiML webhooks. This doesn't mean that the information provided in the request of a TwiML webhook couldn't be delivered via Event Streams. It just means that there is no bi-directional channel. Any action taken in response can only occur outside of the Event Streams channel and product. Event Streams is not a replacement for TwiML webhooks.
The type of events and data we'll be supporting within Event Streams are similar to the events that Twilio sends via informational webhooks today. However, existing webhooks have a few shortcomings. First, HTTP falls short as a transport when customers require at-least-once delivery of their data. If a webhook fails for any reason — e.g., an error within Twilio or an error from the customer's server — then that event is lost and can't be sent again. Additionally, there is no backpressure mechanism built into HTTP that prevents customer servers from being overwhelmed by unanticipated traffic volume.
Event Streams does not replace your applications' existing webhooks. However, Twilio plans to offer the same webhook data in Event Streams for customers that need at-least-once delivery. Twilio also plans to expose some Twilio data via Event Streams that is not available via webhook today. Apart from webhooks, Event Streams supports Amazon Kinesis and Segment sinks.
Additionally, the model and format for the data sent over our existing webhooks is inconsistent. Event Streams adopts a consistent format for all data, making it easier to consume when a customer is using multiple products or a product that is built on top of multiple products, such as Flex and Studio.
We started with Amazon Kinesis and Webhook Sinks because they were requested by several early customers. We're also investing in additional Sink types such as Azure Event Hub, GCP Pub/Sub, and more. Please let us know what other Sink types you're interested in using with Event Streams.
Event Streams supports both ISVs and direct customers. Customers can configure Event Streams for subaccounts, but there is no way to receive events from all subaccounts with a single Event Streams subscription at this time. Instead, create an Event Streams subscription for each subaccount.
Ordering is not guaranteed at this time, so users still need to rely on the event timestamp to determine when an event was generated.
Twilio makes delivery attempts using exponential backoff logic, so there's no fixed number of attempts. However, Twilio does not continue retrying after four hours of failed attempts.
Twilio has implemented URL extensions that can be added to the standard HTTP webhook URL. These extensions give you the ability to override Twilio's default HTTP callbacks connection settings on a per request basis. See the complete list of overrides supported. For the Webhook Sink type, Event Streams currently supports all the overrides.
Event Streams only supports the Server Name Indication (SNI) and Edge Location overrides. Since delivery guarantees are included with Event Streams by default, the overrides for connection timeout, read timeout, total time, retry count, and retry policy are not supported.