HTTP(S) action step

Need to access data from an external source? The HTTP(S) step is the solution for you.

Updated over a week ago

After reading this article, you'll learn how to:

  • Configure the HTTPS step

  • Retrieve data from a different place

Getting started

The HTTPS step is one of the standard action steps within the action builder. It's also one of the most powerful steps in the standard set of steps since it allows you to connect to a variety of services, be it retrieving-, sending-, updating-, or deleting information.

Before you use the HTTPS step, you need to know what you want to do with it. For this article, we'll take a use case to request a user from another website. We'll use the JSON placeholder fake rest API to achieve this. The user that we'll retrieve from the API will then be created as a user in our own Betty Blocks application.

Building the action

We start the use case off by retrieving a user. Create a new action called something similar to 'Get and create a new user'. The next step is to drag the HTTPS step onto the canvas.


The method used in this use case is GET. While our focus is on obtaining user information, it's important to note that there are other methods available. Below, we will describe these methods and illustrate when each would be used, using a bank account as an example:

  • GET is like viewing your account details

    Imagine you're logging into your bank account to check your balance or view your transaction history. You're not changing anything, just getting information about your account. GET requests are like that, they're used to retrieve information about a website account from a server without modifying it.

  • POST is like adding money to your account

    When you deposit money into your bank account, you fill out a form with the amount and submit it. You're adding new information to the system. POST requests are like that, they're used to create new website account data on a server.

  • PUT is like transferring money to another account

    If you want to transfer money from your bank account to another account, you'll need to initiate the transfer. You're changing the balance of your account. PUT requests are like that, they're used to update existing website account data on a server.

  • DELETE is like closing your account

    If you decide you no longer need your bank account, you can close it and remove all your information. You're removing yourself from the system. DELETE requests are like that, they're used to remove website account data from a server.

Retrieving a user

As stated, for our use case we'll use the GET method:

Overview of the HTTPS step using the GET method

To retrieve a user I used the following URL:


This retrieves user 3, the output variable is named response, this variable is then added to the finish step.

Creating the models

If we now test the action in the playground, we can see the following result:

The data received from JSON placeholder API using the playground

As the response shows a user named 'Clementine Bauch' is retrieved, now there's a lot of information besides the name, so let's create a model to save some of that data into. This is the Webuser model I created to save the users to:

The properties of the webuser model

To add new records to this model, we'll need to pass the users we retrieve into it. This can be simplified by creating a schema model for the data that we're retrieving. In the image of the response from our playground, we see a lot of data. We don't need everything as we can see in the Webuser model.

With the Webuser model in place, we're able to save data to it. We can do this easily using a schema model in our HTTPS step. The schema model will allow us to map through the response, making it easier to assign the data to the properties of our Webuser model. This is especially helpful when using the response in a create or update step.

Let's create the schema model with the same properties as our Webuser model.

The properties of the schema model

The properties we'll work with from the response

Note: the schema model's properties are lowercase, this is because it has to match with the properties that we retrieve in our response.

Right, with the model and schema model in place, we can continue working on the action. What we want is to save the retrieved data in the Webuser model.

Creating new users in our application

Head back to the action and select the schema model we just created in the HTTPS step.

Assigning the newly created schema model in the HTTPS step

Save the step and drag a create step on the canvas. Select the Webuser model, add the properties, and select the response from the HTTPS step. As you notice, there's an arrow button on the response variable.

Creating a new record with the option to map throught the values of the response thanks to the schema model

If we click on the button, we see the properties that were earlier defined in the schema model.

The mapped values from the response

Assign these values to the properties of the Webuser model.

Assining the values from the response in a create step

The finished create step should look something like the image above.

Add the new_webuser variable to the finish step. If we test this action by running it in the playground, we'll see that a new webuser will be created based on the data of the response from the HTTPS step.

A new webuser being created from the data we retrieved in the response

And there we go, we just created a new webuser based on the response we received.


The headers are made for extra information, you can define the content type like the request or response is JSON or XML. Other extra information, such as API keys is also defined in the headers if you need this information differentiated per API that we use.

Headers informing the request what kind of content to expect

URL parameters

Right now, the user we retrieve is static in the URL, it'll always retrieve user 3 no matter what. Let's make use of the 'URL parameters' to make this dynamic. First of all, add an input variable in the start step called 'user_id'.

Creating an input variable

In the HTTPS step, create a new URL parameter and assign the user_id to the URL parameter. We can use liquid to add the variable to the URL making it dynamic.

Using the input variable in the URL of our request

If we test the action, you'll see a new field that we can add as a query variable in the playground.

The input variable in the playground pop-up

In the playground, we can replace "Number" with an actual number like so:

Specifying what user we want to retrieve the data off within the playground

And if we run this, a new webuser will be created with the response from the action.

The response from the newly created webuser based on the data we put in

There we go, the user Ervin Howell has been created successfully.

Query variables

Query variables can be seen as extra information for the response, a good example of this is adding a limit to the response. You might've seen this in URLs that have been shared with you, you have a regular URL like:

But it has a question mark after it with certain names, like 'limit':

The URL above requests all users but limits the display to a maximum of 3. For instance, if there are 10 users in total, it will only show the first 3.

If we put the response variable back in the finish step, then we can see what the response yields in our playground. If we configure the query variables like this:

A query paramater limiting the amount fo objects returned to 3

Then the URL will become:

Resulting in the following response:

The response of 3 users using a query parameter

It looks like a lot, but If you count the IDs of the users you can see just 3 users.

You can add multiple query parameters. Besides limit JSON, the placeholder also provides a 'sort' functionality. If we sort the users based on their website, the query parameters look something like this:

Showcasing a limit but also a sort based on the users their websit from the sponse

This results in 3 users, sorted in alphabetical order based on their website:

The repsonse we get based on the query paramaters limited to 3 and sorting based on the website property

You can see that we get different users now from the response.

Body parameters

Body parameters are used primarily with POST, DELETE, and PUT requests. In your request, you can specify what data you want to send with your request. Do this by first creating body parameters and then adding those in the body using liquid. If you, for example, want to send the data of a user to a JSON placeholder, the body and body parameters will look like this:

Body and body parameters within the HTTPS step, based on a specified webuser

In the example above, we created a webuser variable filtered on a specific ID, but this can be any of your webusers. The webuser variable contains the data of Billy. If we change the method to POST, and we send this data to the following URL:

This will give us back (if our request is valid) the data of the user Billy. Make sure to check out the JSON placeholder's guide on their website to learn how you can work with the other methods as well. Next, save your action, and let's check if this works as we expect by testing it out using the playground.

If we run the action, we can see that JSON placeholder response properly by throwing back the data we send to it:

The results of the POST we did based on the body we sent in our request

There we go, there's Billy.

You now know how each option works within the HTTPS step. We have plans to create more in-depth articles with real-life use cases soon, so make sure to watch out for those!

Did this answer your question?