With HTTP Client, we provide maybe a different way to do this, but itโs still possible though likely a bit more manual. The Http Client has a pagination section (which you can expand - see the screenshot below)
The best way to explain these options is that the โHas nextโ input should evaluate to a boolean to determine if there are more pages to get or not (so in your case, if $entities.length < 10 would likely be what you want to enter here, that would break the pagination if you have fewer than 10 entries in your output document. The โTotal pages to fetchโ would be a secondary block for stopping pagination, so if you wanted to get all pages, youโd never set the โTotal pages to fetchโ if you want to limit the number of pages to however many are available up to 10, youโd set that value to 10. Override URI is the uri youโd have to request to get the next page, in this case (for offset paging) youโd have to do some work to get this working, if your original request url is something like https://example.com/api/output with query parameters of count 10, then you could either change to โreuse request parametersโ and define the new ones there, or change the full url completely to something like "https://example.com/api/output?count=10&offset=" + (snap.out.totalCount * 10). This would allow your offset to increase by 10 for every output document produced, etc. You could do this either in the โOverride URIโ or in the โOverride parametersโ to support this capability. Youโll somewhat note that these are both only visible when the checkbox is checked, so that will determine which process it takes. Typically, โOverride URIโ is useful for cursor-based pagination and โOverride parametersโ are useful for count-based pagination assuming you externalize all of your query parameters and the triggers are able to be set via the query parameters rather than path parameters.
