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.

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

To retrieve a user, we used the following URL:

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

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

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:

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.

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.

Head back to the action and select the schema model we just created 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.

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

Assign these values to the properties of the Webuser model.

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.

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.

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'.

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.

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

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

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

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

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:

Then the URL will become:

Resulting in the following response:

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:

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

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

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:

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:

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!