API
Keeping your system in sync with updated_after
The pattern for mirroring Gorilla Dash contacts and leads into another system: the first full load, then incremental polling that cannot skip a record.
Last updated September 2, 2026
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 withresults_per_page=1000until 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_afterset 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.
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.
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.