Skip to contentSkip to navigationSkip to topbar
Rate this page:
On this page

Event Streams GA Migration Guide

Event Streams is now General Available (GA), and as part of the transition from Public Beta to General Availability, Twilio has made some changes that you should be aware of.

These changes are part of Twilio's ongoing effort to improve the reliability of the service while reducing the cost of delivery of these events.

Update to static IP address when using Webhook Sink

update-to-static-ip-address-when-using-webhook-sink page anchor

Beta behavior

beta-behavior page anchor
  • For Twilio accounts with Static Proxy enabled, Webhooks generated by Event Streams originate from a specific list of fixed IP addresses.
  • Starting October 1st, 2023 , regardless of whether Static Proxy is enabled or not, Webhooks from Event Streams will originate from the new CIDR range of .

This update aligns with Twilio's ongoing efforts to streamline and standardize the Event Streams infrastructure. This change ensures a consistent experience across all configurations, whether Static Proxy is enabled or not.

To continue uninterrupted receipt of Webhooks from Event Streams, complete the following task:

  • Add the new IP range to your allow list.


This change only affects Webhooks generated by Event Streams. Other Twilio webhooks are not affected.

Changes to Event queueing

changes-to-event-queueing page anchor
  • The maximum number of queued events allowed is five million.
  • The maximum queueing duration for deliver is 24 hours.
  • The initial delivery attempt is made within two seconds following the reception of the event by Event Streams.
  • There is no cap on the number of queued events.
  • The maximum queueing duration for delivery is four hours.
  • The majority of events are expected to be delivered within the two second time frame, but two second latency is not guaranteed.

These changes were made in order to optimize performance and resource utilization.

Please note that this change applies to both Webhook and Kinesis destinations. Both often experience retries due to customer-side rate limiting - as indicated by 429 HTTP status codes for Webhook, and Provisioned throughput exceeded(link takes you to an external page) errors for Kinesis.

  • You may need to review and possibly adjust your current Event Streams setup and workflows to accommodate this new queueing time frame.
  • Ensure that your systems are prepared to handle the new maximum queueing duration of four hours.

Changes to Sink Validation Process

changes-to-sink-validation-process page anchor
  • The Sink Validate Resource is used to confirm that a Sink has been properly configured and is ready to receive events.
  • Creating a Kinesis Sink requires a validation step.
  • Webhook Sinks are active by default but can be validated if desired.
  • There is no longer a Sink Validation step.
  • A request to create a new Sink Validation resource always returns a result property with a value of valid . (This is to avoid disrupting existing customer workflows.)
  • The status of Kinesis and Webhook Sinks are active by default.

These changes were made in order to provide a more efficient and user-friendly experience.

Changes to Password-Protected Webhook destinations

changes-to-password-protected-webhook-destinations page anchor
  • Both Basic and Digest authentication schemes were supported in webhooks, although requiring a two-way HTTP roundtrip.
  • Only Basic authentication is supported, with no extra HTTP roundtrip.

These modifications were implemented to improve performance and use resources more efficiently, as the previous approach of making two HTTP requests is highly inefficient.

To continue receiving webhooks protected with Digest authentication:

  • Change it to Basic authentication, or
  • Remove user-based authentication from the webhook and start relying on Twilio signatures and/or the source fixed IP address range.

Rate this page: