Intercom Conversations Pagination

[markdep]

Environment

• n8n version: 1.86.1
• Database: Default (SQLite)
• n8n EXECUTIONS_PROCESS setting: Default
• Running n8n via: Cloud

---

Hi all — I’m hoping someone has figured this out already and I’m just missing something obvious.

I’m trying to use the Intercom conversations search endpoint with the HTTP Request node in n8n, including cursor-based pagination. The endpoint expects a body structure like this:

{
  "query": {
    "operator": "AND",
    "value": [
      {
        "field": "updated_at",
        "operator": ">=",
        "value": "timestamp"
      }
    ]
  },
  "pagination": {
    "per_page": 30,
    "starting_after": "Wz..." // <- must be inside here
  }
}

I’ve tried a few methods to get this working:

This works (but without pagination):

If I send the full JSON body manually using the “JSON” content type and don’t touch the HTTP node pagination settings, I get results back as expected. Example body (obviously enough only sending per_page to test response).:

{
  "query": {
    "operator": "AND",
    "value": [
      {
        "field": "updated_at",
        "operator": ">=",
        "value": "timestamp"
      }
    ]
  },
  "pagination": {
    "per_page": 30
  }
}

Response:

[
{
"type": "conversation.list",
"pages": {
"type": "pages",
"next": {
"page": 2,
"starting_after": "WzE3NDQzMjE1MjUwMDAsNzc5MjksMl0="
},
"page": 1,
"per_page": 30,
"total_pages": 10
},
"total_count": 280,
"conversations": [

Pagination fails with both raw and JSON methods:

I tried using n8n’s built-in pagination options to automate the starting_after cursor, but in all tests it ends up inserting starting_after at the root of the body, not inside the pagination object where Intercom expects it. For example, n8n tries to send this:

{
  "query": { ... },
  "pagination": {
    "per_page": 30
  },
  "starting_after": "cursor" // <- not valid for Intercom
}

I tried:

• Raw mode with JSON.stringify() and pagination options enabled
• JSON mode using the structured fields method
• Manually assigning the value using expressions like ={{ $response.body.pages.next.starting_after }}

But it always fails or loops on identical responses because the pagination isn’t nested where it should be.

So my question:
Has anyone successfully used the HTTP Request node with Intercom’s cursor-based pagination and got starting_after to insert correctly inside the pagination object?

Or is the only workaround right now to build a manual loop in the workflow to inject starting_after into the body manually for each request?

Appreciate any insights!

[roman.pankovski]

Has the same problem with Intercom.
tried to use pagination.starting_after in node options with no luck.

Try to use workaraund with IF + Merge nodes to collect all items.

[roman.pankovski]

Node 1: w/o starting_after in Body
Node2: with starting_after and value is pointed to Node 1 {{ $json.pages.next.starting_after }}

If node used for checking “If there exist next.starting_after”.

Hope this helps, but speed of this solution is very sad… Even with 150 items per request.

[markdep]

Thanks @roman.pankovski, that’s the route I’ll have to take.

Problematic pagination handling. Perhaps a feature request to the built in pagination tool to detect pagination objects is needed.

[roman.pankovski]

@markdep also check Intercom Scroll API
This endpoint not is in the latest version of API, but I found it in v1.3

For example: Scroll over all leads

Hope this helps!