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.
