BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Interviews Developer Evangelist Jon Gottfried on App Development with Twilio

Developer Evangelist Jon Gottfried on App Development with Twilio

Bookmarks
   

1. We are here at QCon San Francisco and we are here with Jon Gottfried, developer , evangelist of Twilio and we are going to learn all about exactly what is Twilio, Jon?

Twilio is a cloud communications platform. That means we have developed an API for developers to send and receive text messages and make and receive phone calls from web and mobile applications. It is a pretty widely used platform now and really commends any application that has access to a web interface, to a web API.

   

2. Who would use Twilio services?

We actually have customers in any number of different verticals. One of the most common use cases that is across any company, is notifications. Any company in some way needs to communicate with their customers and text messaging, we found, is one of the most effective and least noisy ways to communicate and send alerts to a user base. We really see that being a common factor, no matter what industry you are in that you need to be able to notify and communicate quickly with the customers. But we have actually seen a pretty wide variety of use cases. A lot of companies are using us now to power their call centers, many companies use us for security, to send out two-factor authentication and verification codes and we have really seen quite a number of other ones as well.

Martin: Tell us about how a person can buy a phone number from Twilio and how they can access it.

The way I like to think about Twilio is that in a typical web application you have a domain name that points to your app. That is the way that everyone in the world accesses it. On Twilio, phone numbers behave in a similar way. So, you have a phone number that lives on top of your application. You can buy phone numbers in any number of countries. I actually believe we have around 50 available right now and that phone number can be interfaced with by the user as if it were their friend’s phone number. There is really no difference to the end user and they could send messages to it, they could make phone calls to it and all of that data, all of those interactions are passed along to your application so that you can respond in a natural way and a unique way for your specific use case and customer base.

   

3. You can be here in the United States, if I bought a phone number, where would it be from? Would it be from another country?

In the US here you can actually buy any number of local phone numbers. So you can buy one from your specific town, your specific city, you could buy toll free numbers which are a little more generic and that applies to many different countries as well, so in Canada you can buy local numbers, in the UK you can buy local numbers, in many countries you can buy mobile numbers and really, it is pretty broken down depending on where you live and where your users live.

   

4. How do app developers go about using Twilio to add telephonic features such as the ability to make and receive phone calls and receive voice mail, Jon?

Sure. Twilio is at its core and API platform and what that means is that we enable developers to add our functionality and integrate our infrastructure into their applications using a standard rest API. So, making HTTP requests to a server is actually the way you interact with Twilio as a developer. To the user – obviously they never see any of that, but as a developer it is fairly standard, just as if you were submitting a form on a web site or just as if you were contacting an API to find out some data about the user’s Twitter stream. That is the same way you interact with Twilio: you make a post request, you make a GET request and we would return data to your application. For incoming it is slightly different but along the same lines. So when you receive an incoming text message or when you receive an incoming phone call Twilio adds an application. We will actually contact your server and use a URL you provided to figure out the instructions for what to do next. So, we might make a post request to your URL and look at the response from your application to determine what to do after that.

   

5. And my URL would then be interpreted by the user as their phone number?

The user never sees the URL. It is purely in the background and it is purely how your application interacts with Twilio as a service. The user is purely interactive with the phone number, so they are just sending a normal text message on their phone or just making a phone call on their phone and in the background we are communicating over this restful API. But to them it is a completely normal phone interaction.

   

6. And for a phone number, is there like a monthly charge? A user pays a monthly charge?

Yes. Technically the application developer pays the monthly charge, but certainly some developers transfer that cost to their users, but the phone number is only one dollar a month.

Martin: That is pretty good.

Yes. We have seen developers provision and deprovision phone numbers at will and you can do all that via the APIs so when you have a new user sign up, you can buy a new phone number and if, for whatever reason, they change their service plan, you can get them a different phone number, you can get them more phone numbers or less phone numbers and it is all done via the API. We have a standard restful interface.

   

7. And the restful interface, that is good for developers developing for Android or iOS, or even for Windows and Mac? Do they each have to do something different or is it a different download? Is the same API offered for each one?

Yes. The way that most restful APIs work and certainly the way that Twilio works is that any programming language that can access web services - that means any programming language that is web enabled – can use Twilio. The most basic way of doing that is by making requests to URLs, but we actually provide a number of different helper libraries and wrap that entire process. So rather than making a request to a raw URL you could actually use the library and access the Twilio API using a more language standardized method. So, if you are doing Java, for example, there are classes and methods that help you access the Twilio API so that you do not have to construct the URLs and all the authentication parameters yourself and that is standard for really any language developers use. For Android and iOS it is slightly different. Our main offering in Android and iOS are actually called Twilio client. Twilio client is a VoIP solution.

What that means is that within your application that you are building, your mobile application, you can actually create an entire phone system, communication system that the user can use without leaving the flow of your App. So imagine building a customer serviced App for a Bank and someone goes to click on a transaction that they are really concerned about, maybe it is fraud, and up in the corner you can have a “Call us” button and when you click that “Call us button” and it does not take you out of the App to the phone – I get that in most applications – it actually initiates a connection over your data to call the customer service line and we can actually pass along contextual data as well, which is the really cool part, right? Not only are you making a phone call, you are making a call that has metadata associated with it. So the agent on the other end could know the transaction number you are talking about, they could know that you are already authorized in this application, they can really see a lot more that is going on because you are using this SDK rather than just the link to a phone number.

Martin: I see. So it is sort of like chat in a way.

Yes, in a way. It is a way of interacting with the communications network that uses data connection and uses your application interface rather than directing them to a phone number outside of the App.

   

8. That is just a little bit different for the Android and the iOS as opposed to if you are doing it on Windows or Mac. They get a little bit more features?

Yes. You can actually create the same type Twilio client interface in a browser and that would work on Windows or Mac or Linux even but the way I like to think about it is that that Twilio client which is ioS, Android and browser is a separate product from SMS and Voice. SMS and Voice typically interact with an application server whereas Client is more user facing. You are creating an interface that allows the user to communicate with your company or service whereas with SMS and Voice it is more typical that the user would be using their existing cell phone and using SMS and their phone app to communicate with their phone application rather than using this unique interface you have created.

   

9. End users get the benefit of telephoning from App developer products. Incorporating Twilio will truly be able to call landline phones, cell phones, syntax messages and long distance calls, Jon?

Yes. Twilio actually does not discriminate on whom you are calling. What that means is that as you are building an application, you can provide a phone number to Twilio as your destination number and we will interface with that very similarly to how a user does. You can provide us with a land line number, a toll free number, a mobile number and it really does not matter and when that does come into play is when you start looking at international calling. For international, the pricing actually does vary based on country and based on carrier and it also varies somewhat on what prefix you need to provide. In the US is + 1 but that prefix changes depending on carrier and depending on nationality.

   

10. And time or length of call also?

No, the length or the call is not limited by whom you are calling. At least not on Twilio’s end.

   

11. What relationship does Twilio have with domestic and international phone service providers?

Sure. We actually work with a number of different carriers both here in the US and abroad. Recently we actually launched a partnership with a carrier called KDDI in Japan. We really see these carriers as like core infrastructure providers for this telephony product we have. There are certainly products we have that go across multiple carriers but we really to have as wide a array of carriers and connectivity as we can so that we can create a great experience for all the developers using Twilio.

   

12. How many customers does Twilio have today?

The last published number we released was around 175,000 customers. When you think about that 175,000 customers who are developing applications powered by Twilio. Each of those customers is probably dealing with thousands or millions more of their own. So it is this massive, massive scale where even though we are only dealing with developers, those developers are really empowered to go out and create their own massive customer bases. We have actually powered more than 1.5 billion calls today. That is a massive, massive number and when you break it down it actually means that Twilio applications have interacted with 20% of the entire world. That is a huge, huge array of people, that is a huge, huge population and it is really more than 300 million individuals that these applications have been interacting with.

   

13. Can you provide us some other statistics about Twilio’s growth in the telephoning market place?

Sure. As far as growth, last year at the Twilio Con we announced that we have made 500 million calls. This year at Twilion Con we announced that we made 1.5 billion. So when you look at that, it is not only tripling in one year, it is actually a very, very steep curve of growth there. Because Twilio has been around for five years now, so just in the last year alone we have really tripled the number of calls we have made. And we have seen a similar trend in SMS where people are messaging more and more people and larger and larger populations.

And we really attribute that to the success of all the developers that we work with. Certainly we are working really hard on scaling and creating a good experience for developers. But really, the developers who build applications powered by Twilio are the ones that are reaching all of these users. They are creating good experiences, they are creating compelling products and they are really building these massive user bases that use us to communicate with their customers.

   

14. Have you had any interesting experiences while exhibiting here at QCon San Francisco, Jon?

Yes. It is a really interesting conference for me personally because I really come from a more of a hobbyist hacker background. And a lot of the people I have met here at QCon are very longtime carrier enterprise developers. And so the way that people look at problems is very unique. And I think it is really fascinating because the scale of the problems that a lot of these developers are dealing with and a lot of these developers are thinking about are very, very different from any startup. I personally love talking to them about what architecture problems they are facing, what they are thinking about as far as the latest technologies and how they are dealing with new models like Cloud APIs like Twilio and I love learning from all the institutional expertise that is here.

   

15. Do you have any security advice for Twilio developers?

Sure. I think that security is something that needs to be baked into every application from the get go and Twilio certainly can assist with that. So, one of the biggest things we see people asking for these days is two-factor authentication. When you think about securing an account, being able to tie a physical device to a user’s authentication is extremely, extremely valuable and we actually implemented it in our own account dashboard as well.

And so I think my advice is that when you are thinking about how to secure your application, you need to be sure that not only are you protecting them with a user name and password but you should also plan on protecting them with some kind of physical or backup verification as well. So that you really know that the person who says they are accessing your application really is the person whom you think is accessing it.

As far as building applications on Twilio and securing them, I think that you have to always be conscious of what customer information you are sending and how your own application server interacts with third party APIs. I think that Cloud APIs have reached the point where they are secure and where they are safe to deal with.

But I also think that you should always be conscious of how you are transmitting customer data. And what third party services you are transmitting that to. I think that with Twilio in particular we see a lot of people sending notifications and sending alerts to customers.

And obviously that is completely safe to do. But you never want to, for example, transmit a credit card number via SMS. There are certain precautions you need to take and there is a very fine balance to figure out what data is OK to transmit and what data you need to lock down in a more secure fashion.

   

16. What is in the future, Jon, for your travels with Twilio as evangelist developer? What is the next step? Are you going to another conference from here?

I am actually headed out to a couple of more conferences. Tomorrow I am going to Monterrey, Mexico for a conference called IncMonterrey which is showing off all the awesome technology going on down there. Then next week I will be back in San Francisco for Dream Forest, which is another great conference where we have been involved in. I am personally very excited to go out to Hawaii now that we have phone numbers there. I think that there is definitely a developer scene there that can be worked with.

Martin: Thank you for being with us, Jon. We have been talking to Jon Gottfried, developer evangelist at Twilio here at QCon San Francisco 2013.

Thank you.

Jan 20, 2014

BT