Pagination and sync

Pages

• limit sets the page size, 1 to 100. It defaults to 25. A bigger limit is a 400, never a quietly shorter page.
• has_more says whether another page follows.
• next_cursor is where it starts. Send it back as starting_after. It is null on the last page.

curl "https://api.hatcel.com/bookings?limit=100&starting_after=eyJ0IjoiMjAyNi0xMC0wOFQwMzowMDowMC4wMDBaIiwiaSI6IjBmOGZhZDViIn0" \
  -H "Authorization: Bearer $HATCEL_API_KEY" \
  -H "Hatcel-Version: 2026-10-08"

Why a cursor

A page number moves when a booking lands mid-read, so page 2 repeats or skips a row. A cursor names the last row you saw, so the next page starts right after it however the list grows. Treat it as opaque: one this API did not issue is a 400.

Incremental sync

Every list takes updated_since, an ISO 8601 instant. To keep a copy up to date:

1. Note the time, then page through the whole list once.
2. Next run, send updated_since set to the time you noted, and page through what comes back.
3. Upsert each row by its id, and note the new time.

A customer's tags and lists come on the customer, so a tag added to them shows up as a changed customer.

Filters

Each list takes the filters its reference page names, and nothing else: an unknown parameter is a 400, so a typo is never read as "everything". An id filter with a malformed id matches nothing.