Introducing Request Replay: An Easier Way To Debug and Deploy Your Twilio Apps

At Twilio, we’re constantly looking for new ways to give developers greater visibility into their applications.  Tools like the API Explorer, App Monitor, and Test Credentials help make Twilio applications easier to operate, debug, and deploy.

Today we’re happy to introduce you to a new feature in that same family, Request Replay, making it easier for you to debug applications and compare failed requests against one another.

Side By Side Comparison

The Request Inspector tool gives developers insight into the response of their web server and the TwiML Twilio executes. But, when a request fails, developers are left to their own devices to reproduce the problematic request and debug it in the context of their application. That’s where Request Replay comes in.

In the App Monitor and Call Details page, you can find a log of all the requests Twilio makes to your application. Once you’ve identified a failed request, you can replay it and see the side-by-side difference between the two responses.

The replayed request is identical to the original. Twilio will send all the same header and request information. You can even play the request back against a different endpoint, so you can test a failed production request against your development server.


Request Replay is a big step forward in making developing and debugging Twilio applications a more seamless process for developers.  We hope you think so, too and we can’t wait to see what you build using it.

  • jboutros

    This sounds really cool! Is there a way to identify a replay request when it comes into our system? We have some logging that happens when we respond to requests from Twilio, and we would need to disable it for replay requests.

    • Hey @jboutros! Your initial request will be on the left side of your account logs, your replayed request will be on the right. As far as setting up function that helps your logs differentiate between an initial request and replay request, we’d be happy to help you find a solution. Can you ping

  • Awesome! There’s loads of times I’ve had issues receiving web hooks locally and this may have solved it. Thanks!

  • Brad Goodman

    Sounds cool! But what I *NEED* are “test” numbers that we can use to mimic “dummy” calls. Ones that will return things like “wrong numbers”, and “busy” and “answering machines” and stuff. Why? Because my code needs to deal with them – and I need to be able to TEST these cases before I just unroll a big application. This has been the hinderance us deploying a Twillo-based app. We can’t just use dozens of real-users’ actual phones (landlines and mobile/SMS) to do this kind of development, debug and regression testing!

  • Tahir Ahmed

    It is extremely helpful and make our life easier. thank you so much. Just need to get a work around as @jboutros:disqus ! asked. We really need to differentiate the initial and replay requests.

  • Is this functionality exposed in the API somewhere?