Skip to main content
This is the first thing most integrations do. It uses one endpoint, GET /v1/members, and the two mechanics that make a sync resumable: cursors and updatedSince.

1. Create a token

Use a service token (Settings → Developers) rather than a personal one. A service token belongs to the organization, so the sync keeps running when the officer who set it up graduates. Scopes: members:read — each member already carries the groups they belong to. Role: viewer, since a sync that only reads should not be able to write. The secret is shown once. Store it as a secret in your own system; if you lose it, revoke and reissue.

2. Read the first page

Members are returned oldest-change-first. isActive: false means archived — Dueflow never deletes a member, so archived rows keep appearing and your system should mirror the flag rather than dropping the record.
Phone numbers, guardian and emergency contacts, custom fields and internal notes are deliberately absent from every API response in v1. If your integration needs one of those, tell us which and why — it’s a decision about what leaves the platform, not an oversight.

3. Walk the pages

Pass nextCursor back verbatim while hasMore is true:
Cursors are keyset-based on (updatedAt, id), so a member edited while you’re mid-walk is never silently skipped or duplicated — which is exactly what offset pagination does.

4. Keep it current

Store the highest updatedAt you saw. Next run, ask only for what changed:
Use the watermark from the previous run rather than “now minus an hour”: a watermark can’t lose a record to clock skew or to a run that took longer than its interval. Overlapping slightly is harmless — you’ll re-apply an update you already have. A full nightly re-read is fine too. At 100 rows a page, a 500-member roster is 5 requests out of 600 per minute.

Nationals: reading your chapters

With chapters:read a national can enumerate its chapters and read each roster:
Only direct child chapters are reachable; anything else is a 404. Two things to plan for:
  • Roster reads are priced by page sizeceil(limit / 25) units, so 100 rows costs 4. A 200-chapter sync at 100 rows a page spends 800 of your 600 units per minute, so it will need to pace itself. See Rate limits.
  • The chapter can see you read it. Each cross-organization read appears in that chapter’s own activity log, naming your organization and how many members were returned. That transparency is the reason the access exists; treat it as a feature to mention to your chapters rather than a surprise for them to find.

Writing back

Creating members is POST /v1/members with members:write and an Idempotency-Key:
A duplicate email returns 409 conflict. To archive rather than delete, use PATCH /v1/members/:id with {"isActive": false} — there is no delete.