Pagination & filtering

Two styles exist, on purpose. Which one an endpoint uses is visible in its response.

Cursor — for anything that grows at the head

Delivery logs, integration sync history, conversations, messages. These lists gain rows at the newest end continuously, so an offset shifts under you between one page and the next: you would see a row twice and miss another entirely.

bash

curl "https://api.zapyflow.com.br/api/integrations/sync-jobs?limit=50" \
  -H "Authorization: Bearer $ZAPYFLOW_API_KEY"

json

{
  "jobs": [ ... ],
  "nextCursor": "cmt1naffo00113tuykpbzlvm9"
}

Pass it back as ?cursor=. A null cursor means you reached the end. Do not construct cursors yourself — treat them as opaque.

Page number — for stable, small collections

Contacts, orders, catalog items. These are browsed by a human who expects “page 3” to mean the same thing twice, and their write rate is low enough that drift is not a practical problem.

bash

curl "https://api.zapyflow.com.br/api/contacts?page=2&limit=50" \
  -H "Authorization: Bearer $ZAPYFLOW_API_KEY"

limit is capped at 100 everywhere. A request for more is clamped, not rejected — but do not build on the clamp; ask for what you want.

Filtering

Filters are plain query parameters with fixed vocabularies (status, from, to, search). There is no filter expression language, and there will not be one: a grammar nobody reads is a permanent source of parsing bugs on both sides.

Dates are ISO-8601. Where a filter means “a day”, the day is resolved in the workspace's timezone, not UTC — an order placed at 21:00 in São Paulo belongs to that day, not to the next one.