Display Node.js and Twilio Helper Library versions

Sometimes, such as when you are migrating to the latest version of Node.js, you want to verify what version of Node.js your Functions are running on. The same can apply to the version of the Twilio Node.js Helper Library that you are using, since its version determines what functionality is available via the context.getTwilioClient helper.

The following code sample shows some helpful values that you can return or log for verification. To get started, follow the instructions below to create a Service and Function to host and execute the example.

Create and host a Function

In order to run any of the following examples, you will first need to create a Function into which you can paste the example code. You can create a Function using the Twilio Console or the Serverless Toolkit as explained below:

ConsoleServerless Toolkit

If you prefer a UI-driven approach, creating and deploying a Function can be done entirely using the Twilio Console and the following steps:

Log in to the Twilio Console and navigate to the Functions tab. If you need an account, you can sign up for a free Twilio account here!
Functions are contained within Services. Create a Service by clicking the Create Service button and providing a name such as test-function.
Once you've been redirected to the new Service, click the Add + button and select Add Function from the dropdown.
This will create a new Protected Function for you with the option to rename it. The name of the file will be path it is accessed from.
Copy any one of the example code snippets from this page that you want to experiment with, and paste the code into your newly created Function. You can quickly switch examples by using the dropdown menu of the code rail.
Click Save to save your Function's contents.
Click Deploy All to build and deploy the Function. After a short delay, your Function will be accessible from: https://<service-name>-<random-characters>-<optional-domain-suffix>.twil.io/<function-path>
For example: test-function-3548.twil.io/hello-world.

The Serverless Toolkit enables you with local development, project deployment, and other functionality via the Twilio CLI. To get up and running with these examples using Serverless Toolkit, follow this process:

From the CLI, run twilio serverless:init <your-service-name> --empty to bootstrap your local environment.
Navigate into your new project directory using cd <your-service-name>
In the /functions directory, create a new JavaScript file that is named respective to the purpose of the Function. For example, sms-reply.protected.js for a Protected Function intended to handle incoming SMS.
Populate the file using the code example of your choice and save. Note A Function can only export a single handler. You will want to create separate files if you want to run and/or deploy multiple examples at once.

Once your Function(s) code is written and saved, you can test it either by running it locally (and optionally tunneling requests to it via a tool like ngrok), or by deploying the Function and executing against the deployed url(s).

Run your Function in local development

Run twilio serverless:start from your CLI to start the project locally. The Function(s) in your project will be accessible from http://localhost:3000/sms-reply

If you want to test a Function as a Twilio webhook, run: twilio phone-numbers:update <your Twilio phone number> --sms-url "http://localhost:3000/sms-reply"
This will automatically generate an ngrok tunnel from Twilio to your locally running Function, so you can start sending texts to it. You can apply the same process but with the voice-url flag instead if you want to test with Twilio Voice.
If your code does not connect to Twilio Voice/Messages as a webhook, you can start your dev server and start an ngrok tunnel in the same command with the ngrok flag. For example: twilio serverless:start --ngrok=""

Deploy your Function

To deploy your Function and have access to live url(s), run twilio serverless:deploy from your CLI. This will deploy your Function(s) to Twilio under a development environment by default, where they can be accessed from:

https://<service-name>-<random-characters>-dev.twil.io/<function-path>

For example: https://incoming-sms-examples-3421-dev.twil.io/sms-reply

Your Function is now ready to be invoked by HTTP requests, set as the webhook of a Twilio phone number, invoked by a Twilio Studio Run Function Widget, and more!

Log and return version data

Copy and paste the following example code into your newly minted Function. Ensure that your Function is public, save your changes, and deploy the Service that contains this Function.

Log and return versions

1exports.handler = (context, event, callback) => {
2  // PATH represents the relative path of this function
3  // This value does not include the domain name
4  const path = context.PATH;
5  const nodeVersion = process.version;
6  const twilioVersion = require('twilio/package.json').version;
7
8  console.log(`Function path: ${path}`);
9  console.log(`Node.js version: ${nodeVersion}`);
10  console.log(`Twilio Helper Library version: ${twilioVersion}`);
11
12  return callback(null, {
13    status: 'complete',
14    path,
15    nodeVersion,
16    twilioVersion,
17  });
18};

While running live logs (click Enable live logs in the Console), make a GET request to your Function using a tool such as curl or Postman. You will then see logs displaying the Function's path, as well as the versions of Node.js and the Twilio Helper Library. Your HTTP client will also receive the same data as JSON.

For example, a public Function named /versions would log the following (with different versions, depending on when you're reading this):

1Function path: /versions
2Node.js version: v14.18.1
3Twilio Helper Library version: 3.72.0

It would also return the following JSON response:

1{
2  "status": "complete",
3  "path": "/versions",
4  "nodeVersion": "v14.18.1",
5  "twilioVersion": "3.72.0"
6}

(information)

Info

This sample uses context.PATH to log the relative path of this Function. There are several other helpful, built-in process variables that you may wish to log as well.