Reading enquiries out of Gorilla Dash

GET https://api.gorilladash.com/api/v1/enquiries returns your leads, with the contact behind each one, the custom fields they filled in, the tracking parameters they arrived with and the source Gorilla Dash calculated.

This is the endpoint to build a mirror of your leads in another system — a CRM, a data warehouse, a dashboard.

Filters

Parameter	What it does
`page`	Page number, from 1.
`results_per_page`	Up to 1000. Defaults to 100.
`tribe_id`	Only leads for one tribe. Organisation keys only.
`person_id`	Only leads from one contact.
`created_date_from`	Leads created on or after this date.
`created_date_to`	Leads created on or before this date. Must not be earlier than `created_date_from`.
`updated_after`	Leads changed since this timestamp. The one to use for syncing.

The two created_date filters work on whole days. updated_after works on the full timestamp, down to the second, which is why it is the right filter for a poller.

A tribe key is hard-scoped to its own tribe. Asking it for a different tribe_id is refused with a 403 rather than returning nothing, so the mistake is obvious.

What comes back

Field	Notes
`id`	The enquiry id. Same value `POST /enquiries` returned.
`organisation_id`	Owning organisation.
`created_at`	When the lead arrived.
`updated_at`	When the enquiry row itself last changed.
`record_updated_at`	The later of the enquiry and its contact. Cursor on this, not on `updated_at`.
`submit_url`	The page the form was submitted from, if known.
`calculated_source`	The worked-out source: Paid Search, Organic Social, Direct and so on.
`tribe_id`, `tribe_slug`, `tribe`	The one tribe this lead belongs to. Null if it was never routed.
`enquiry_form`	The form it arrived on, by name.
`person`	The contact: id, name, email, phone in both display and international form, business name and address.
`fields`	The custom field answers, as name and value pairs.
`enquiry_url_parameters`	The tracking parameters, as name, value and path.
`enquiry_sources`	Your own named sources, matched from the parameters above.

ONE TRIBE, ALWAYS

An enquiry belongs to exactly one tribe, and that is what the payload returns. Do not build anything that expects a list of tribes on a lead.

Polling for new leads

Results come back oldest id first. That is deliberate and it is what makes safe polling possible — see the guide on keeping your system in sync for the full pattern.

Note the wall-clock time your poll started.
Call the endpoint with updated_after set to the time your previous poll started.
Page through until you have everything.
Store this poll's start time as the cursor for next time.

DO NOT CURSOR ON THE NEWEST TIMESTAMP YOU SAW

A bulk change stamps many records with the same timestamp. If your cursor is the highest record_updated_at in the results, records sharing that exact timestamp on later pages are skipped and never come back. Cursor on the time the poll started instead.

A lead counts as changed when the enquiry itself changed or when the contact behind it changed — someone corrected the email address, added a phone number. That is what record_updated_at reflects, and it means a contact correction reaches your mirror without you polling contacts separately.

This endpoint is deliberately not cached, so a lead pushed a second ago is readable immediately.

A first full load

For the initial copy, omit updated_after entirely and page from the start with results_per_page=1000. Once you reach the last page, switch to the polling pattern above with a cursor set to when the full load began.