Universal Connector HTTP Request Step Tutorial

The Quick Connector is advised to only be used in custom integrations or internal use cases, not templates. Review Compatibility Comparison before utilizing the Quick Connector in workflows.

Covering

• Setting Up the HTTP Request Connector
• Configuring Paging and Response Fields
• Adding Authentication to the Connector
• Finalizing the Connector Setup

In this video, we’re going to take a look at the new Quick Connector HTTP Request functionality. 

Setting Up the HTTP Request Connector

First things first, you need to drag the connector step into your workflow. Once the step is in place, you have the option to either delete the step or configure its setup. For this demonstration, we’ll focus on the setup process.

In the setup window, you can see you’re allowed to make a request to a specific host. At the end of the setup process, all you have to do is click “Create” to save your changes.

For this demonstration, we are using the PokéAPI, with a simple GET request to list all of the Pokémon that are available. 

So, the first thing you’ll need to do is specify the type of request. In this case, we are making a simple GET request. After selecting GET, enter the appropriate API endpoint. For this example, we’ll use the PokéAPI to list all available Pokémon. We are not adding any specific identifiers (like ID or name), to make sure that we get pages within the request, and can page through the data. 

For this example, there’s no query string parameters and there’s nothing for a header. The PokéApi does not require authentication, either, but we will go through what the authentication will look like in a separate example later.

Configuring Paging and Response Fields

Paging, however, is something that we need to consider. To configure the paging settings for your Quick Connector HTTP Request, click on Next, or click on the Paging tab in the Step Setup.

For our example, we are going to turn on inbound paging, and set the page limit to 60, which represents the number of items to be returned per page. The rest of the settings naturally depend on the documentation of the API you are working with. For our PokéAPI example, we are setting the Page Size Target Name as “limit”. The API also has Page Offset Target Name (“offset”), but no Page Number Target Name, so we can ignore that.

There is, however, a Next Page URL Target Name. So when using that, what we can actually do is take the response. And in this instance, it’s as simple as a ResponseField called “next“. That ResponseField will be taken and pushed through, and that will be our next URL that we would be targeting and looking for.

For this example, we are going to set this off with the “limit” and “offset”. Later we will set up a version with the Next Page URL Target Name as well. 

Now that the paging is set up, next what we want to look at is the Request and the Response Fields. You can navigate to the Request/Response tab by again clicking on Next or just clicking on the tab itself.

Now, there is no request when it comes to our PokéAPI example, but there are Response Fields that we essentially are given. So in the Response Field, we put in our example response.

We have a top level object called results, and within that, it holds an array of items. So what you can do, is paste an example of the working JSON object with all of the information that you need in terms of the fields. Once done, click on Next. You will be taken to the Authenticate/Finish tab, but as this API does not have any authentication, we are not required to put in any.

What you’ll also see is there is an Advanced Settings tab available. Here is where you can add script to the HTTP Request step, for example if you want to format or modify the Request and Response data.

Once you have completed the Authenticate/Finish tab, you can click on “Create”. What you will have now is a working HTTP request that is ready for testing. To test it, click on the Test button that will have appeared next to the Step Setup button. In our example, we see that we get the first 60 results back, and that proves, at the very least, that the offset and limit are working to some extent. 

Now, to make sure that the step works fully, drag on a quick Decision Step and connect it with the HTTP Request Step. And for the source, select the HTTP requests. For the setup, select Results Name for the Field, to check if it exists. Then run the cycle once. And now, it’s been a while since I’ve played Pokémon game, so I have no idea how many pages we’re supposed to get back. But hopefully we get back more than one page and we can see that it’s working. 

So if I look at the step data here, I’ve actually pulled down 1302 individual Pokémon, and it’s splitting those transactions and checking against each of them to see that the name exists or not. Because this is just a database, I’m going to assume everything is, in fact, being pulled down and working correctly. So in this instance, I’m just going to stop the cycle. Okay, so that’s working with the paging. 

Adding Authentication and Finalizing the Connector Setup

Let’s just have a quick look at what setting this up with authentication is like and what that changes overall in the connector. As well as looking at what the Next Page URL would change for us in terms of setup. 

So here we have the Pokémon API once again. Now we’re going to change this to have API key as part of the authentication. We’re going to use the header and just put “Authorization”, and then we’ll go to the next step, which is paging. 

So here we have limit for the Page Size Target Name, the Page Offset Target Name. What we’re going to do is clear the offset one out. And then, what we’re going to do is pull in the field location for the Next Page URL Target Name, which is just “next”, sits at the top, and then we’ll go to the Request/Response tab.

What we’ll do here, at the end of the Response data, is add in a field called “next”, and we’ll leave that blank. We know it’s a URL that’s coming through, but that’s fine. I’ll hit Next, and then you’ll see here that I’m required to put in an API key. Now I’ll just put in a value, and I’ll update the step, and this will save my settings.

Now, in order to just make sure this runs a bit quicker, this time, I’m going to turn off collection splitting, and I’m going to run a test step. Here, I can see that the limit is 60, and we can see that the next page URL has offset 60, and limit 60, I hit run once. 

What I would expect to see is the same number of objects called, but no transaction split, and multiple pages in the response. 

So here you can see I’ve got multiple pages in the request, offset 60, limit 60. Offset 120, limit, 60. And the paging has worked. 

In this instance, what you’ll also see is there’s now an API key header which was missing beforehand, with the authorization redacted, which lets me know that the authorization has worked. It’s been registered, and it’s been successful, as the API key hasn’t inhibited the calls in any capacity.