Get Started

Debugging

Debugging Your Application

Writing an application on Twilio is easy as pie. But here are a few tips we've found helpful...

Check the Logs

Twilio logs information about its interaction with your application, including all errors and warnings. You can check the contents of those logs to help you debug. There are two ways to do this:

Check the Response Body

While errors and warnings related to Twilio retrieving your TwiML are available in the the Twilio debugging interface, the REST API will also return a Twilio REST Exception XML block which contains the HTML error code, Twilio-specific error code, error message, and a link to the Error Code Reference.

<?xml version="1.0"?>
<TwilioResponse>
    <RestException>
        <Status>400</Status>
        <Message>Dial: Invalid phone number format </Message>
        <Code>13223</Code>
        <MoreInfo>http://www.twilio.com/docs/errors/13223</MoreInfo>
    </RestException>
</TwilioResponse>

All Twilio-specific errors are listed in the Error Code Reference.

The Browser Is Your Friend

Remember, you're just writing a web application. There's nothing Twilio does that you can't test right there in your browser. Visit the URLs in your web browser, and see that you don't have any errors.

  • Firefox treats XML files really nicely, highlighting any invalid XML in your document. We're not forcing you to use Firefox or anything, we're just saying it's cool... that's all.
    • Using Firefox, you can easily see if your application is returning valid XML. Firefox will show you encoding or other errors in your XML, which is helpful.
    • Mimic Twilio's data passing by manually adding data to your URLs. For example, if you ask Twilio to digits and the action is http://www.myapp.com/handleDigits.php, you can open your browser to http://www.myapp.com/handleDigits.php?Digits=1 to verify what happens if the user presses 1.

Debug Output From your Application

Make sure your application isn't sending debug output, because that will nearly always cause problems. You can, however, wrap any such output in XML comment blocks... they're the same as HTML comment blocks: <!-- COMMENTS HERE -->

Check for HTTP Redirects

Twilio is a well-behaved HTTP client, so when it receives an HTTP 301 or 302 redirect it will follow it to the specified URL. However, on the subsequent request the original parameters are not included. Occasionally you may see parameters such as 'Digits' or 'RecordingUrl' not arriving where you expect them. In this case, check to make sure the URL is not returning a redirect.

As an example, when a <Gather> request is made to the action URL, a 'Digits' parameter is included in the POST request. If the action URL redirects to another URL, Twilio will follow the redirect and issue a GET request to the specified URL. This GET request will include the standard set of parameters included with every Twilio request, but will not include the additional Digits parameter.

Common situations that may return unexpected redirects are:

  1. A server that automatically redirects all HTTP requests to HTTPS
  2. A URL rewriting rule that rewrites request URLs to include or exclude 'www.'

To see what your server is returning to Twilio, create a test request using cURL, hurl.it or your HTTP client of choice and inspect the response returned from your URL.