Quickstart

First, we'll create a Service, which serves as our container for the environments we set up.

We'll get back a Service SID, in the format ZSxxx.

Next, we'll use that Service SID to create a "dev" Environment.

This will give us an empty environment, e.g. demo-X4HX-dev.twil.io. To see the domain name for your environment, you can fetch your environment using the ZExxx SID output from the prior code sample.

Now let's create our Function. We create the Function at the service level, not inside a particular environment (we'll deploy our Function to an environment later on). Also, we only set the name for the Function at this step. We'll choose a path, visibility, and upload the code for the Function in later steps.

You will get back a Function SID in the format ZHxxx. Save this Function SID for the next step, where we'll create a Version for this Function.

With a Function created, we're ready to create our first Version. Versions of Functions or Assets are where you add the path, visibility (public, protected or private), and the file content itself.

First, we need some code upload. Let's write a simple Function that decides the fate of the universe:

Now we have a Function worth uploading. Save this as a file on your computer named firstfunc.js.

Now we can upload that file. The create API action is not currently represented in the helper libraries, so you have to do a manual file upload in the language of your choice. See an example below using Node.js.

Remember to replace ZSXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX with your Service SID, and ZHXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX with the SID of the newly created Function (from this step).

With the upload complete, you will see a SID logged to your terminal. Save this Version SID for the next step.

Now, we need to create a Build. A Build will compile Function and Asset Versions into a single, deployable package. This build will live in the Twilio cloud, so you just need the Build SID to reference it — there are no files to keep track of.

You'll receive a result straight away, but note the status property. We need to wait until the status returns completed before continuing. The best way to handle the status changes is to poll every second or two. Here is some sample code to get the current status of a Build:

When the build is completed, we're ready to deploy!

For the final step, you must associate the Build we just created with the Environment we created earlier in this tutorial. (Remember the Environment SID!) This is called a Deployment.

Your Function will now be live and accessible via URL! You can test it out by going to its URL, such as https://demo-X4HX-dev.twil.io/thanos (be sure to replace demo-X4HX-dev.twil.io with the unique domain name for your Environment, which you fetched earlier).

When creating a build, you can also specify any dependencies that your code may have.

To do so, include the dependencies property, which must be a JSON stringified array of package names and versions.

The pattern we used above for uploading Functions is exactly the same as it for Assets.

1. Create an Asset
2. Create the Asset Version via a POST request to the serverless-uploads.twilio.com domain
3. Include the AssetVersion SID(s) we want to be a part of the Build, alongside any functionVersions and dependencies we might need.

Definitely take a look at the API reference section for all of the API resources below. You might be particularly interested in Variables to allow setting Environment Variables for a given Environment.

• Service
• Environment
• Function
• Function Version
• Asset
• Asset Version
• Variable
• Build
• Deployment