Skip to main content
Retrieving test data with HTTP(S) step

How to request user data from an external resource using the HTTP(s) action step.

Updated over a month ago

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.

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, we used the following URL:


โ€‹jsonplaceholder.typicode.com/users/3

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 HTTP(S) 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: schema model's properties are lowercase, this is because it has to match 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 HTTP(S) 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 HTTP(S) 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.

Headers

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 HTTP(S) 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:

jsonplaceholder.typicode.com/users

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

https://jsonplaceholder.typicode.com/users?_limit=3

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:

https://jsonplaceholder.typicode.com/users?_limit=3

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:
โ€‹

jsonplaceholder.typicode.com/users

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 HTTP(S) 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?