Twilio Error 11200

Twilio raises Error 11200, "HTTP retrieval failure," when it makes an HTTP request to one of your URLs (a voice/messaging webhook, a TwiML URL, a status callback, or a fallback URL) and cannot retrieve a usable response. Per Twilio's official error reference, this covers three situations: your server returned a non-2xx status, the connection itself failed, or Twilio reached your server but could not parse the response.

This is a server-side / network error on your endpoint, not a problem inside Twilio. It commonly appears in the Twilio Debugger for voice calls and SMS.

What causes Twilio Error 11200?

• Your endpoint returned a 4xx or 5xx status. Twilio treats anything outside the 2xx range as a retrieval failure. A 404 (wrong path), 401/403 (auth), or 500 (app crash) all surface as 11200.
• The connection failed or never completed. DNS resolution failed, TLS handshake failed, or a firewall, WAF, or rate limiter dropped Twilio's request.
• Your server took too long to respond and timed out. For voice, Twilio waits roughly 15 seconds for a response, and that budget includes TCP connect and TLS handshake time. Long DB queries or synchronous third-party API calls inside the handler blow this budget.
• The URL host resolves to a private/localhost IP (e.g. 127.0.0.1, 10.x, 192.168.x). Twilio's servers cannot reach it — use a tunnel like ngrok for local testing.
• The endpoint rejects HTTP POST. Twilio POSTs to webhooks by default; static .xml/.html files served by web servers that only allow GET return an error.
• HTTP basic-auth that Twilio can't satisfy, or a redirect pointing to an invalid/unreachable destination.
• Missing or mismatched Content-Type. TwiML must be served as application/xml or text/xml; a mismatch can make the response unparseable.

How do I fix Twilio Error 11200?

1. Open the Twilio Debugger and inspect the failed request. It records the exact URL Twilio called, the HTTP status it received, and a timestamp/Error SID — start there to see whether you got a 4xx/5xx, a timeout, or a connection failure.
2. Hit the URL yourself the way Twilio does — a POST, from a public network — and confirm it returns a 2xx with valid TwiML: bash curl -i -X POST https://your-app.example.com/voice You should see HTTP/1.1 200 OK, Content-Type: text/xml, and a <Response>...</Response> body.
3. Make the URL publicly reachable. Verify it resolves to a public IP (not localhost/private), is served over a valid certificate, and that no firewall/WAF/rate limiter is blocking Twilio. Check your server access logs to confirm Twilio's request actually arrived.
4. Respond fast, then work asynchronously. If the handler does slow work (DB writes, external API calls), you will hit the timeout and Twilio will retry — running your handler twice. Instead, acknowledge immediately with an empty 200 OK or 204 No Content per Twilio's guidance, and queue the work for background processing.
5. Allow POST and check static files. If the TwiML lives in a static .xml/.html file, configure the web server to allow POST to that path, or serve it from an app route.
6. Replace HTTP basic auth with webhook signature validation so Twilio is not blocked by an auth challenge it cannot answer.
7. Set a fallback URL on separate infrastructure so a single host outage doesn't drop the call/message.

If 11200 is intermittent, collect the timestamps and Error/Call SIDs from the Debugger before contacting Twilio support — that's what they need to trace it.

If you send via Courier, your Twilio webhook configuration and endpoint must still satisfy these requirements; 11200 reflects Twilio's request to your URL, so the fix lives in your application/server, not in Courier.