A number of TechRepublic members have asked me about sending text messages from an application, and it’s something I wanted to do for a long time, but there were always barriers. I’ve seen various systems for sending text messages, but the configurations puzzled me. Kannel, for example, requires the administrator to set up access to all of the various carriers that you deal with and configure each one individually. It’s a mess.
A few weeks ago, I sat down to assist with an integration between Wodify (one of the projects I am currently working on) and Twilio, a service that provides text message and other telephony services. It was a fantastic and painless experience!
One of my big concerns about working with third-party services is that, in the last few years, they all seem to prefer REST over SOAP. I understand why, but for a .NET developer, SOAP is very easy to consume (just point Visual Studio to the WSDL, and you are basically done). REST seems to be more work; it gets even worse when the REST service decides to use OAuth authentication. To work with a REST service in .NET ends up requiring a bunch of third-party libraries and more effort than dealing with a SOAP service. Most of these services throw developers to the wolves with a poorly documented (and often out of date or flat-out inaccurate) API and some scraps of sample code.
You can imagine my delight when I discovered that not only is Twilio well documented for the most part (I had some confusion around callbacks and TwiML), but that they offer pre-made libraries for accessing it. I used the “official” .NET library with great success. With extraordinarily minimal work, I was able to get my system up and running, sending text messages through Twilio. I would show the code I wrote, but it was nothing more than what the library’s home page says to do. The results give you back a message ID that you can use to check the results, and you can optionally specify a callback URL for when the message is sent (it will post the message ID, letting you know that it is ready for you to check on it).
The one cautionary note about using this service is that the callback will have the price of the text message as a field, but it will often show as 0. Checking the message immediately after sending will also often show 0 for the price, but when you go to the Twilio site, you will see the real price. This is because it can often take a few seconds for Twilio to actually get the price, but they perform the callback so quickly that the price is not available yet. I suggest that you either wait a minute or so after getting the callback to get the price if you need it, or retry periodically until the price isn’t 0. In addition, Twilio can ping a callback URL when a new message is received. I used the same URL handling for both scenarios, and it worked like a charm.
Overall, the Twilio service is fantastic. The text messages send instantly from our application and are fairly priced ($0.01 per message when sending to a phone in the United States). The callbacks are extraordinarily quick as well. The site and their applications are easy to use. If you need to add text or other telephony capabilities into your application, Twilio is a winner.
We were able to get our application integrated with text messaging with roughly two hours of work on the Twilio side (we still needed to build out a lot of UI and other handling on our end for a messaging system), and I think our users will be delighted. Working with the library showed me a lot of additional functionality, including the ability to make and receive phone calls, which I will definitely keep in mind for future use.
Keep your engineering skills up to date by signing up for TechRepublic’s free Software Engineer newsletter, delivered each Tuesday.