The way people communicate has changed over the last few years. When was the last time you called a service-number because you had a problem? For me, this is already years ago, and I most often use chat interfaces when they’re available.
These new interfaces are usually automated to a certain extent – it’s hard to tell if a human or a machine is replying to your question. Developers have the power to build interfaces that go beyond what we’re used to. Alexa, Whatsapp, emails, SMS – you can automate all these channels.
Twilio is a communications API that enables you to tailor the experience to your needs. Want to do an SMS poll? No problem! Need a custom chatbot on your landing pages? Sure thing! Want to bring all your friends into a group phone call? Easy peasy!
Webhooks – the foundation of future interfaces
As a developer, you probably won’t build the infrastructure to send SMS or make phone calls. You’ll use SDKs and APIs for that. The way it works is that you can use Twilio’s RESTful API to initiate outbound communications. Phone calls, SMS, WhatsApp messages are only one HTTP call away.
The other way around is a little bit trickier. How do you react to incoming messages or phone calls when you’re not controlling the infrastructure receiving these events? Webhooks build the foundation for that.
If someone sends a message, makes a phone call, or uses any other channel a webhook is sent to a URL you define. The response of the webhook controls what happens next.
In the above example, you see the flow for an incoming SMS. A user sends an SMS, Twilio handles this event and makes an HTTP request to your app to find out what to do next.
But do you want to build a whole app to respond to an HTTP request? Or could a serverless function do the job?
