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.
- 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 184.108.40.206/25.
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 220.127.116.11/25 to your allow list.
This change only affects Webhooks generated by Event Streams. Other Twilio webhooks are not affected.
- 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 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.
- 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
activeby 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
resultproperty with a value of
valid. (This is to avoid disrupting existing customer workflows.)
- The status of Kinesis and Webhook Sinks are
These changes were made in order to provide a more efficient and user-friendly experience.
- 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.
Security Action required
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.