Tips for Taking Twilio to Production

I’ve been fortunate to work with the Twilio API at each of my professional jobs. In fact, I’ve often said that I’ll end up integrating with Twilio when I start my own company. The value that Twilio provides is pretty incredible, making it possible to easily handle calls, SMS, and other telecom functionality. I’ve put together some tips if you’re looking to use and ship Twilio Voice to your customers. Some of these tips will be development related and others will be business requirement related that you may not consider up-front.

• Utilize subaccounts for customer separation
• Fully understand billing and how to get usage for any account
• Provide instructional material / troubleshooting for customer environments
• Use ngrok to make local development a breeze
• Understand latency requirements of your TwiML endpoints

Utilize subaccounts for customer separation

Twilio supports subaccounts which provide a way to separate customer environments into many mini environments. Using subaccounts will allow your phone numbers, apps, billing, etc. to be completely separated from each other. This removes the possibility of allowing customer A to use customer B’s phone numbers when placing calls, for instance.

Aside from separation being a good practice that might save you in the case of a programming bug, the bigger reason is that Twilio’s billing will be broken out per subaccount. While the credit card on file for the main account will be used to pay for services, the billing and usage records can be seen per subaccount. There is no other way (short of aggregating all calls yourself) to do this billing delineation. Even if you are able to aggregate the cost per call, there may be other charges that you cannot predict which aren’t as easy to separate when using 1 account.

When you’re using subaccounts, you can treat all API calls exactly the same, the difference is that they are made with a different API credential. While you have to handle creation and maintenance of the subaccounts, your coding shouldn’t be much more difficult.

Fully understand billing and how to get usage for any account

On a similar note as using subaccounts for billing, get ahead of what types of charges you will accrue and why. Twilio doesn’t provide an interface to see your costs per subaccount without viewing every single subaccount individually. You may need to write custom code using the UsageRecord API which can be placed into your database of choice and aggregated as needed in order to achieve costs per subaccount.

On top of your actual bill, the usage per subaccount can be very important. Despite Twilio being awesome at fraud prevention, it will happen that fraudsters try to target your application. They place calls through high-cost routes and siphon the money that Twilio pays to use those routes. You can get ahead of this by setting up UsageTriggers. Using these triggers will allow you to be alerted when certain spending thresholds are passed in Twilio.

From a business perspective, I would recommend connecting with your financial team to make sure they have what they need to document the Twilio charges correctly.

Provide instructional material / troubleshooting for customer environments

Telecom is hard, for the service providers and for your customers. Voice data requires a reliable internet and computer setup. You will absolutely run into issues where customers are not able to use Twilio services due to issues on their end which may not be obvious even after troubleshooting.

Do research into VoIP requirements and prepare material for your own customers. Maintain your own knowledge base with up to date resolutions based on your learnings over time. Never dismiss an issue being something very simple like a microphone not working or a bad network.

networktest.twilio.com is a great resource for doing site surveys for customers. I suggest running 10 60s tests over 10 minutes and taking the minimum result as the stable network available for VoIP.

Use ngrok to make local development a breeze

This one might be clear to most people who have done Twilio development. However, I felt that I needed to include this tip as ngrok is my #1 Twilio development tool; I wouldn’t be able to develop easily without it. ngrok provides tunnels from the open internet to a local port on your machine. You can point ngrok to your local server and then Twilio can access it over the internet without any firewall changes.

ngrok does cost money, but I’ve gotten by on the free tier so far. It requires updating any TwiML apps when you restart ngrok, but it will operate the same otherwise.

Don’t just use ngrok for a simple tunnel. Make use of the local admin port (4040) to see what traffic / responses have been proxied through your server. This is invaluable to diagnose why Twilio or your server choked on a request.

Understand latency requirements of your TwiML endpoints

Telecom is very latency sensitive. When Twilio initiates a phone call, it’s going to do at least 1 round trip to your server, if not more depending on your setup. If your server is struggling to keep up with web requests and holds them in a queue, you will end up dropping or delaying your phone calls.

Consider placing your Twilio endpoints on dedicated servers that aren’t serving other traffic in order to avoid latency spikes caused by other sections of your application. Also ensure that your Twilio endpoints are fast in normal use case to decrease your time spent on each request.

Most importantly, keep an eye on your throughput and performance and setup alerts for when something goes wrong.

I hope that these tips help you out with your Twilio implementation. You’re sure to learn more as you deploy your first application, or scale an existing application, but the growing pains will be well worth it in the end.