FAQ

How are Event Streams different from TwiML webhooks?

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.

How are Event Streams different from Twilio’s informational 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 will eventually support many “Sinks”, starting with Amazon Kinesis and Webhook. Event Streams will not replace existing webhooks, but Twilio plans to offer the same webhook data in Event Streams so customers needing at-once delivery can leverage Event Streams. Twilio also plans to expose some Twilio data via Event Streams that is not available via webhook today.

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.

Is Twilio planning to offer other sinks?

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.

Does Event Streams support indirect customers (ISVs)?

Event Streams will support both ISVs and direct customers. Customers can configure Event Streams for subaccounts, but there is no way to roll up an Event Streams subscription for all subaccounts within a project at this time.

Is order-of-events delivery guaranteed?

Ordering is not guaranteed at this time, so users will still need to rely on the event timestamp to determine when an event was generated.

How many delivery attempts will be made in 24 hours?

We’ll make attempts using exponential backoff logic, so there’s no fixed number of attempts.

Are Webhook Connection Overrides supported for the Webhook Sink type?

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.

However, after the beta period, Event Streams will only support the 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 will not be supported.