Skip to main content
Operations that can return many items — leads, the leads of a list or a post, engagements, events, posts, deliveries, workflow matches — answer one page at a time:
When has_more is false, next_cursor is null: you have read everything.

Read every page

Call again with cursor set to the last next_cursor, with the same filters and the same sort, until has_more is false.
In n8n, the HTTP Request node does this for you: under Options › Pagination, choose Update a Parameter in Each Request, set the query parameter cursor to {{ $response.body.page.next_cursor }}, and stop when {{ $response.body.page.has_more }} is false.

What the cursor guarantees

  • Nothing is missed or repeated while you read, even while TIKT writes new leads. Pages are cut by the sort order and the item’s identifier, never by position: a lead written while you read never shifts the others.
  • A lead written while you read may not appear in this pass if it sorts before your current page — for example a new lead when you read newest first. You will get it at your next sync: see Syncing changes.
  • The cursor is opaque: don’t build or change it. A cursor that can’t be read, or that comes from another sort, is refused with 400 and the code curseur_invalide. Start again without cursor.
  • A cursor doesn’t expire, but it only makes sense with the filters it was made with.

Lists that are not paginated

A few lists are always short and come whole, with data only: your lists (GET /v1/lists), your tracked profiles, your blocklist, your workflows, your destinations, the event types, a lead’s scores.