HTTP Pagination with POST Request Body Parameters - $pageCount not incrementing

[simon.lewis]

I am attempting to use the new pagination option in the HTTP Request node (great feature, by the way). The API I am accessing requires a page number to be sent in the body of a POST request. Seems like an easy case for the new feature. However, when I run the node, it executes 3 times (I set a 3 loop limit for testing) but submits the same $pageCount every time. Looking at the examples and other forum posts, I should not need to increment the value of $pageCount explicitly … but do I ?

Workflow (creds have been obscured)

Share the output returned by the last node

Last node is large - result is 3 sets of the same data (the HTTP Request node called POST-GetConversations is requesting the same page number each time)

Information on your n8n setup

• n8n version: 1.18.0
• Database: PostgreSQL
• n8n EXECUTIONS_PROCESS setting (default: own, main):
• Running n8n via Docker
• Operating system: Linux (Raspbian / Debian Bullseye 64bit)

[n8n]

It looks like your topic is missing some important information. Could you provide the following if applicable.

• n8n version:
• Database (default: SQLite):
• n8n EXECUTIONS_PROCESS setting (default: own, main):
• Running n8n via (Docker, npm, n8n cloud, desktop app):
• Operating system:

[simon.lewis]

@n8n

• n8n version: 1.18.0
• Database (default: SQLite): PostgreSQL
• n8n EXECUTIONS_PROCESS setting (default: own, main): main
• Running n8n via (Docker, npm, n8n cloud, desktop app): Docker
• Operating system: Linux (Raspbian / Debian Bullseye 64bit)

• n8n version: 1.18.0
• Database (default: SQLite): PostgreSQL
• n8n EXECUTIONS_PROCESS setting (default: own, main): main
• Running n8n via (Docker, npm, n8n cloud, desktop app): Docker
• Operating system: Linux (Raspbian / Debian Bullseye 64bit)

[Jon]

Hey @simon.lewis,

I used this option about an hour ago for a workflow I was building, Can you remove the paging.pageNumber from the initial request that way the pagination will add it as it needs it.

[simon.lewis]

Thanks @Jon . Done. That makes sense. Still getting the same results in each page submission, tho. That is, it executes 3 times as expected but returns the same for each. I checked the Developer Console - seems to show only one POST but missing the paging.pageNumber object.

I have the paging params as follows:

I also tried this (editor shows NULL above so tried ternary operator):

Same result (POST shows no paging.pageNumber in the Body)

Seems spot-on to me but am I missing something ?

[Jon]

Hey @simon.lewis,

The null looks to be correct, I have just given this a quick test against webhook.site and it looks to be working for me with the number incrementing as expected.

Can you try the below as a quick test and see if you are also getting the same output.

Request 1

Request 2

Request 3

You can use this URL to check the run of the workflow to see the output: Webhook.site - Test, process and transform emails and HTTP requests

[simon.lewis]

Yep, same result (correct paging values on the webhook site) so there is not something screwy with the n8n instance. Mystery !
I am gonna rebuild my flow from scratch and try again. If all else fails, I’ll put in a paging loop the old way. Thanks.

[Jon]

Hey @simon.lewis,

I think I have just worked it out… I gave it another go using your http request node and that was when I spotted this…

{
  "order": "asc",
  "orderBy": "conversationStart",
  "interval": "2023-11-20T00:00:00/2023-11-24T23:59:59",
  "paging": {
    "pageSize": "10"
  },
  "paging.pageNumber": 3
}

It looks like we are sending paging.pageNumber as a key rather than adding pageNumber to the existing paging object. I will get a bug ticket created for this on Monday morning but I think this explains the issue.

[simon.lewis]

Ahhh. I cant see that in the console (but could be reading it wrong !) but would certainly explain it. Thanks for the effort on this one - much appreciated.

[Jon]

Hey @simon.lewis,

It looks like we don’t actually output the pagination data to the console either so I will open a ticket for that as well.