In their own words: Twilio Functions is a serverless environment to empower developers like us to quickly and easily create production-grade event-driven applications that scale with your business.
The focus of Twilio Functions is to replace the need of having your own scalable server, expensive development of common tasks, by just using an instance that is running side by side with your Twilio Flex contact centre.
This is what they aim to achieve:
Secure By Default - Automatically ensure that only Twilio requests can execute your function.
Serverless - Offload your operational burden to Twilio and skip maintaining any infrastructure.
Autoscaling - Automatically add capacity to meet the unique demands of your application.
Native Twilio Integration - Use Functions as a first class member of the Twilio console with a pre-initialized Twilio REST Helper Library built in.
Lower latency - By running your code directly on Twilio, you’ll minimize the time it takes for your instructions to reach Twilio.
Familiar environment - Functions are written in Node.js and can deliver TwiML/json structured data and have access to helper libraries (npm), API keys, uploaded assets, …
Pricing: callbacks to an environment Twilio Function has a $0.0001 per invocation, first 10,000 are for free.
It’s always good to remember that Twilio Functions is still in beta, so plenty of this may vary.
Previously, when a user sends a message or calls a Twilio number, we use callbacks set up to make an http request to our own servers. Twilio Functions replaces the server and handles this http request themselves, so developers don’t need to handle authentication, tokens, TwiML responses, etc …
You would probably want to configure your environment first, giving your Functions access to the ACCOUNT_SID and AUTH_TOKEN in order to initialise your Twilio client (as you would do with an SDK)
You can also set any external API tokens or npm dependencies (modules) that you may want to use on your code, as environmental vars. Initially you will find some helper libraries loaded by default, like lodash.
You can now start composing your Functions, associating them to a particular event to be triggered, and giving them an endpoint if they are to be run by http requests from your own code.
This one in particular mocks the response to an incoming message, using Twilio Studio flow, passing down parameters to compose a message in said
In a real world environment, the Function would have called an API, obtaining the client’s number from the ‘event’ param and composing it with the output of said call.
A Twilio Function always gets three arguments - context, event, and callback.
The context contains configuration you set on your Twilio Function - you can set environment variables through the console that get passed to the function every time it is executed, and you can also check a box to pass an auth token with your account SID as well. You can use that combination of account SID and auth token to initialize a Twilio REST Client, or use a pre-initialized one that is available on the context.
The event contains any http request parameters passed to the function at the time it was called.
To wire things up, you would need to make your Functions active as callbacks for the different events, associating them to the active numbers for the account, or be consumed as http requests from inside Studio Flows or external implementations.
This would be a helpful Function to allow us to create new Tasks. Any custom params to add would be on the ‘event’ payload. As you see in the example, you can create custom params inside the task attributes to pass on to Twilio TaskRouter.
Makes an Agent join an outgoing conference.