Introducing Twilio Functions — Public Beta Now Open

Twilio Functions serverless computing
  • Write and run Twilio code without dealing with servers.
  • 10k free invocations every month—$0.0001/invocation after.
  • Now available to everyone in public beta.

Today, we’re excited to announce Twilio Functions, a serverless environment to build and run Twilio applications so you can get to production faster. Developers provide Twilio with Node.js code for handling their communication events, such as an incoming phone call, and Twilio executes this code on their behalf, ensuring a seamless communications experience.

In order to understand why we built Functions, let’s first look at how developers build apps without them.

How to send a Twilio SMS message without using Functions

The first step is to stand up a web server that instructs Twilio on what to do for a communication workflow. There are two reasons that Twilio was designed this way:

  1. Twilio communicates events to your software using webhooks. These events span the gamut from incoming SMS messages to new reservations in TaskRouter. Webhooks mean that you can build Twilio apps using any language or framework that you like, so long as it speaks HTTP.
  2. You must use credentials to authenticate to the REST API and to generate access tokens. The credentials and code need to operate in a secure environment.

Although this architecture works great for using webhooks securely, it does cause some problems. Having to stand up a public web server can create a lot of friction for people who just want to prototype a simple solution and test it with users before committing to building it out. Also, developers often run into internet – and HTTP – related issues (DNS blips, proxy configuration, caching behavior) that make it difficult to troubleshoot their Twilio applications. And finally, many customers face challenges with scaling. We’ve heard numerous stories about customers building awesome applications with Twilio, those applications becoming an overnight success, and their web infrastructure falling over due to the load.

We’ve designed Functions to solve these specific challenges. Using Functions, you can build production-ready Twilio applications that respond to Twilio events, mint Access Tokens, and invoke the REST API – all without needing to stand up or scale a web server.

Getting Started with Functions

Getting started is simple. First, visit the Functions section in the Twilio Console. You’ll see a list of your Functions as well as the ability to create a new one. When you create a new Function, you will be prompted to choose a Template to get started with.

Twilio Functions - choose a template

Templates are pre-written code and configuration that help you quickly build a Twilio application. There are currently several templates built-in to Functions that help you do everything from forwarding an incoming phone call to minting a Sync Access Token. For now, select the “Hello Voice” Template.

Now it’s time to build your Function. Make sure your Function has a descriptive name so you can reference it in other parts of the Twilio Console. For now, you can leave it as Hello Voice. Next, set the path for your Function. Every Twilio account is provisioned a unique domain to use with Functions. The combination of your unique domain and the path gives you a fully qualified URL that can be used to invoke your Function. You can set the path for this function to ‘/hello’. Since you used a Template, the code section has been pre-populated for you:

Twilio Function configuration

Functions are written in Node.js and executed in a v6.10 container. Every time your Function is invoked, three parameters are passed-in.

  1. context: variables passed in from your Function configuration such as credentials and environment variables.
  2. event: information about the specific invocation, such as HTTP parameters, that were passed-in.
  3. callback: the method you call to return from the Function.

Click “Save” and your new Function will get deployed to the Twilio Runtime.

Using a Function to Power an Incoming Phone Call

Once you’ve finished writing your Function, it’s time to put it to work! Go to your Phone Numbers and edit one that has the ability to handle inbound phone calls. Scroll down to the Voice & Fax section.

Twilio Functions - Voice and Fax

In the section where we specify what to do when a call comes in,  select Function from the drop-down to the right. Then choose the “Hello Voice” Function that you just created and click Save at the bottom of the page.

Now comes the moment of truth! Give your Twilio phone number a call and your new Function will say “Hello.”


Functions are priced per-invocation. You only pay when your Function is run. All Twilio customers get 10,000 free invocations each month so they can try out Functions and prototype solutions without any friction. Beyond 10,000, each invocation is $0.0001. Volume pricing will be available in the future.

Wrapping It Up

Functions are the newest part of the Twilio Runtime and we’re excited to help developers prototype and build production-grade Twilio application faster than ever. Below are some resources to get help you get started building:

We can’t wait to see what you build!

  • Xavier Lavallée

    Hi! These are pretty cool! But is it normal that gather verbs don’t work? The example for IVR does not add the .say verb to the parent .gather node

    • Hey Xavier. The “simple menu” template written properly to use the new v3 Node helper library, which changed the syntax for generating TwiML. This has since been fixed. The code below show how nesting now works:

      twiml.gather({numDigits: 1})
      .say(‘Welcome to a simple menu. Press 1 2 or 3’)

  • asciimo
  • Brian West

    You could also avoid all this and just use FreeSWITCH, Its free, Has all the capabilities and doesn’t come with Vendor Lock-in. Just saying.

  • Andrew McClenaghan

    What advantage is there to using your cloud functions? It would be great if you provided examples for AWS Lambda, Azure Functions, Google Cloud Functions as they are were most people are already running their code.

    • NickDA

      One would assume latency gains, as these functions will be invoked by Twilio and assuming their networking engineers did their job, should avoid quite a lot of “public internet” jumps. In telephony that latency matters as you have a live human on the other end. (As an aside – they appear contractually like wrapped AWS:Lambda functions, and maybe that’s all they are… but you are paying the premium for them to be invoked in Twilio’s account for the latency decrease).

  • Cool! I’d be curious to know if you built these on your own infrastructure, or leveraged one of the big cloud provider’s Functions products. I thought it interesting that the signature of your functions is similar to some of the other cloud providers, which is great because it somewhat reduces vendor lock-in.

  • I have an VCPU instance running in google cloud platform to host my node.js application which sends a random Bible verse (from an JSON file also hosted). I wonder if Twilio Functions could host all the code instead.

    • Hey Andrew, it sounds like you could do this easily with Twilio Functions. Feel free to ping me at if you need any help.

      • Thanks Carter! I watched your Functions talk from Signal on Youtube and it looks like the JSON file can be hosted on Twilio Assets and referenced from the node code. I sent you an email with the source, have a great day! I hope to scale out so that anyone can receive free Bible messages in text format for a very minimal operating cost by eliminating GCP from the equation.

  • Ciaran

    This looks really cool. We are saving a ton using serverless tech.

    I have a few questions.

    Is there a limit on request per second – for example AWS Lambda is 4 I think.

    How would this work with sub accounts?