When invoking a Web Service, you may have the requirement to retrieve, by setting some input parameters, data sent by group of pages . This can be performed quite easily with the Designer in a process.


This example shows how to retrieve a total of 321 pages, sent by group of 50 in a response.

This is an example of a process to allow the request of an API, iteratively based on an index, a number of pages per call and a total number of pages.

The principle is as follows:

you will invoke the API for the first time to have the total number of pages expected. Then as long as the total number of pages is not reached, you will invoke the API by giving as input the starting index and the expected number of pages.


1- Create a first mapping to retrieve the total number of pages:

To do this, you have to request the API by setting the starting index to 1 and the number of pages to retrieve to 1 too, because what interests us is to have the total number of pages to retrieve.


In this example, we store the starting index, the number of pages per call, and the total number of pages in a table. Other solutions could be considered, including going through variables.



2- Create a second mapping that will be called as many times as necessary to retrieve all the pages:

It is necessary to retrieve the index and the number of pages per call in the storage table, to place them in input parameters.

In output, we retrieve the number of pages per call, which serves as a key to update this record in the storage table, and we update the starting index by adding the number of pages retrieved during the call.



I have not detailed the part of loading the data specific to each page. It works just like in any API call.


3- Create a process to chain API calls

In this process, the actions are linked as follows:

First of all, we call the first mapping (named m-get_total_results).

Then, we add a SQL_Operation to update the storage table with the desired number of pages per call, which we update in a process parameter (named itemsPerPage, and which is worth 5 in my example)

Then, we call the API for the first time, thanks to the second mapping (named m-get_pages).


Then, we make a SQL_Operation to retrieve the current start index and compare it to the total number of pages to retrieve to know if we should continue the invocation of the API or not.

This is what the process looks like:


I detail below the 4 points indicated by a number.

1- SQL_Operation to update the number of pages to retrieve per call:

2- SQL_Operation to update the start index (and read the total number of pages)

3 - We compare the starting index to the total number of pages:

4 - Last iteration: the starting index is greater than or equal to the total number of pages:

Attention: there is a loop in this process: it is necessary that the two incoming links are parameterized in not mandatory (otherwise the loop will be infinite):