Receiving webhooks
Polling
updated_since cursors for clients without an endpoint.
curl "$SEQ/v1/enrollments?updated_since=2026-10-13T09:00:00Z&limit=200" -H "Authorization: Bearer $KEY"
# follow meta.next_cursor until it is null, then remember the time you startedEvery list endpoint accepts updated_since and returns meta.next_cursor, so a client that cannot receive webhooks (a desktop app, a batch job, a locked-down network) can still learn what changed.
| Endpoint | Poll for |
|---|---|
GET /v1/enrollments?updated_since= | status changes, exits, replies and meetings (replied_at, meeting_booked_at), the current step |
GET /v1/tasks?updated_since= | new, completed and expired tasks |
GET /v1/contacts?updated_since= | contact changes (your own writes, mostly) |
GET /v1/senders?updated_since= | channel status changes |
GET /v1/contacts/{id}/timeline | everything about one person |
Doing it right
- Use the time you started the previous poll as the next
updated_since, not the time it finished, and accept seeing a row twice: rows are idempotent snapshots. - Page with
cursoruntilnext_cursoris null;limittops out at 200. - Poll every minute or two; the worker's own loops run every 5 to 60 seconds, and the API rate limit is 600 requests a minute per key.
- Register an endpoint when you can: polling tells you the state, webhooks tell you the event (which signal caused the exit, which delivery failed).