September 10, 2026. On 8 September Twilio put its Webhook Configuration API into public beta. It tells Twilio to fetch an OAuth token from your own authorization server and send it as a Bearer token on every outbound webhook, per URL. That beats putting a username and password in the webhook address. It is also, today, unusable on most of the platforms agencies actually receive those webhooks on.
What Twilio shipped
- Two resources, applied per URL. Webhook Settings hold the authentication and connection config. Webhook Rules bind a Setting to a URL pattern, so different credentials apply to different endpoints.
- Client credentials, refreshed proactively. Twilio uses the OAuth 2.0 client credentials flow against your token endpoint and, in its own words, "when a token nears expiry, Twilio requests a replacement".
- Signature validation is not replaced. Twilio's FAQ asks whether authentication replaces signature validation and answers no: "A signature proves the request wasn't tampered with. Keep validating signatures."
- Shared signing keys arrive alongside it. You can now sign with HMAC-SHA256 using a key you create, identified per request by a new X-Twilio-Signature-Key-Sid header, instead of signing everything with your account auth token.
- API only for now. The changelog says it "will be available in the Console later this year", and no Twilio SLA covers public beta products. Accounts get 50 of each resource type, and changes take 30 to 60 seconds to propagate.
The receiving end cannot use it
We read the documentation for the four platforms our clients actually point Twilio at. Make's custom webhook authenticates with an API key in a fixed header of its own naming, so it never inspects an Authorization header. Zapier's Catch Hook has no inbound authentication at all, and Zapier's own help text says the URL is secured by obscurity and should be treated as a password. GoHighLevel's inbound webhook trigger documents none, and its published remedy for a leaked URL is to delete the trigger and generate a new one. n8n comes closest, offering Header Auth and JWT Auth, but Header Auth stores one fixed value and n8n documents no way to accept a changing one, which is exactly what a rotating Bearer token is.
The sharper point is the one nobody will lead with. Twilio says plainly that OAuth does not replace signature validation, and none of those four platforms documents validating X-Twilio-Signature either. The feature has shipped into a receiving ecosystem that on paper cannot consume either half of it. If your inbound SMS lands in one of those tools, the honest security control today is still the secrecy of the URL.
The new failure mode
Switching this on puts a third system in the hot path of every inbound message. If Twilio cannot exchange your credentials for a token it retries twice, 250 milliseconds apart, then drops the webhook, logs error 97001 in the Debugger, and does not retry that Setting for 300 seconds. For a lead capture line, a five minute outage on your authorization server is five minutes of inbound leads that are gone rather than delayed.
One thing is not happening. Twilio has announced no deprecation date for credentials in the webhook URL, for X-Twilio-Signature, or for HMAC-SHA1 signing. If no Rule matches, Twilio still signs with your account auth token and authenticates itself to nobody. Nothing changes until you change it.
What it means for operators
The part worth doing this month is not OAuth. It is the shared signing keys, because they need no authorization server and they fix a problem every multi client Twilio setup has. Signature validation is keyed on the account auth token, so any integration that verifies signatures needs the credential that controls the whole account. Per integration keys end that, and one rotates without touching the others.
For OAuth itself, the deciding question is what receives the webhook. A custom endpoint or an API gateway can check a Bearer token today and reject unauthenticated traffic before your code runs. A no-code trigger cannot, so budget for a small authenticated endpoint in front of it. Twilio publishes neither the product coverage nor a price, saying only that all customers can use both resources, so scope it per integration rather than account wide. None of this touches your consent obligations: if the traffic is outbound calling, the rules on our TCPA compliant AI calling page still govern what you may send. Wiring and securing pipelines like this is AI automation work.
Frequently Asked Questions
No, and Twilio says so directly. Its FAQ states that a signature proves the request was not tampered with and tells you to keep validating signatures. Authentication proves Twilio is allowed to call your endpoint, while the signature protects the integrity of the request body. They solve different problems and Twilio treats them as independent.
Not on their published documentation. Make's custom webhook reads an API key from a fixed header of its own naming and never inspects the Authorization header. Zapier's Catch Hook has no inbound authentication. GoHighLevel's inbound webhook trigger documents none. n8n offers Header Auth, but it stores a single fixed value and n8n documents no way to accept a rotating one. A small authenticated endpoint in front of the no-code trigger is the practical workaround.
Twilio has not published a price or a plan gate for it. The only entitlement statement in the changelog is that all customers can use both resources. Note separately that reaching your authorization server through static proxy addresses is described as a Twilio Editions capability, so that specific piece is tied to a plan even though the API itself is not stated to be.
No deprecation, sunset or retirement date has been announced for credentials embedded in a webhook URL, for X-Twilio-Signature, or for HMAC-SHA1 signing. All remain documented and supported. If no Webhook Rule matches an outgoing request, Twilio still falls back to signing it with your account auth token and does not authenticate itself to your endpoint at all.