Keeping your system in sync with updated_after

If you are copying Gorilla Dash data into a CRM, a warehouse or a reporting tool, you want each poll to fetch only what changed. The updated_after parameter does that — but there is a right way and a wrong way to drive it, and the wrong way loses records silently.

It is supported on GET /people, GET /enquiries and GET /enquiry-forms.

Two timestamps, and only one of them is the cursor

Field	Meaning
`updated_at`	The record's own row changed.
`record_updated_at`	The record or anything shown inside it changed. This is what `updated_after` filters on.

The distinction matters because a record can change without its own row changing. Move a contact to a different tribe and their row is untouched, but the tribe shown in the payload is different — so record_updated_at moves and the change reaches you. Cursor on updated_at and you would miss it.

Endpoint	What counts as a change
`/people`	The contact's own details, or their tribe link.
`/enquiries`	The enquiry itself, or the contact behind it.
`/enquiry-forms`	The form itself.

The pattern that works

First run. Omit updated_after. Page from the beginning with results_per_page=1000 until you have everything. Before you start, write down the current time — that is your first cursor.
Every run after. Note the current time. Call with updated_after set to your stored cursor. Page through the results and apply them.
Only when the run completes. Store the time you noted in step 2 as the new cursor. If the run failed halfway, leave the old cursor alone and the next run picks up the same window.

THE CURSOR IS THE CLOCK, NOT THE DATA

Never set your cursor to the highest record_updated_at you saw. A bulk change stamps hundreds of records with one identical timestamp; if that timestamp is your cursor, every record tying with it on a later page is stepped over and never returns. Use the wall-clock time the poll started.

Advancing the cursor slightly early is harmless — you will re-fetch a few records you already have, and your writes should be idempotent anyway. Advancing it late loses data permanently.

Send a proper timestamp

Always send a full ISO 8601 value with a time zone offset — 2026-09-01T09:14:00+10:00, or a Z for UTC. Remember to URL-encode it.

A value with no offset is read as UTC. If your system is ten hours ahead, that quietly skips ten hours of changes on every poll, and nothing about the response tells you it happened.

Why the ordering looks odd

Both sync endpoints return oldest id first. Newest-first reads more naturally on page one, but the filter is by timestamp while the ordering is by id — so any batch larger than one page would push the oldest changed records onto later pages, exactly where a consumer that reads page one and stops will never look. Oldest-first makes a full walk safe.

ALWAYS FINISH THE WALK

Read every page before you advance the cursor. Stopping after page one because "the new ones are at the top" is the second most common way to lose records, after cursoring on the data timestamp.

How often to poll

Once a minute is plenty for near-real-time, and sits comfortably inside the rate limits.
Once every 15 minutes is fine for a reporting mirror.
Use big pages rather than frequent small polls — one call for 1000 records costs the same as one call for 25.
A poll that finds nothing is cheap. Do not try to be clever about skipping quiet periods.

Deletions

These endpoints report records that exist and have changed. They do not report deletions, so a record removed in Gorilla Dash simply stops appearing. If that matters to you, reconcile occasionally with a full walk and mark anything absent as gone on your side.

Which endpoints this does not cover

The content endpoints — blog articles, knowledge articles, menu items, digest posts, media, reviews and tribes — do not take updated_after today. They are built for websites that re-read a full list and rely on caching, not for incremental sync. Use ETag and If-None-Match there instead; see the caching guide.