Skip to main content
Polymorfa does not impose one cursor contract on every list route. Parameters are operation-specific and appear in the generated OpenAPI page for that path.

Connection and conversation lists

The Messaging API contract returns typed arrays for session, webhook, contact, group, channel, label, presence, and similar list operations. The current public OpenAPI document does not declare a global cursor query parameter. When a route exposes limit or offset, use only the bounds shown on that operation. The shared Pagination type is:
Do not assume an SDK iterator is lazy or cursor-backed unless that SDK method documents it.

Account and campaign lists

The current method reference declares these query controls:
  • GET /platform/sessions accepts an optional projectId.
  • GET /platform/campaigns requires projectId and accepts an optional projectSlug.
  • Message-template list, get, and delete operations require projectId.
Any additional filtering is part of the operation schema. Reusing a parameter from a different endpoint is not supported.

Cursor-paginated lists

Some list operations declare cursor and limit and return a page object alongside data:
Pass page.nextCursor back as cursor until page.hasMore is false. Treat a cursor as opaque and send it back unchanged. A cursor the operation cannot read, including one issued by a different operation, returns 400. Campaign recipients and audience members use this contract. Both accept a limit of 1 to 100 and default to 25:
  • GET /messaging/projects/{projectSlug}/campaigns/{id}/recipients
  • GET /platform/campaigns/{campaignId}/recipients
  • GET /platform/audiences/{listId}/members
The two recipient operations also accept a status filter.
GET /platform/campaigns/{campaignId}/recipients returned every recipient in one array before September 20, 2026. It now returns one page and a page object. Read page.nextCursor in a loop to get the whole list.

Large exports

For continuous datasets, consume webhooks instead of repeatedly polling a list route.