API
Reading enquiries out of Gorilla Dash
GET /enquiries — the filters available, every field in the response, and how to poll for new and changed leads without missing any.
Last updated October 14, 2026
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_after | Leads created at or after this moment. |
created_before | Leads created strictly before this moment. Must be later than created_after. |
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. |
include_person | Send false to leave out the contact's name, email, phone and address. person then comes back as null. |
include_fields | Send false to leave out the custom field answers, which often hold a name, phone number or message. fields then comes back as null. |
created_after, created_before and updated_after take a full timestamp with its time zone, such as 2026-09-01T00:00:00+10:00, and compare down to the second. URL-encode the timestamp, because a + left as it is arrives as a space: send +10:00 as %2B10:00. The two created_date filters are older and work on whole days in UTC.
To report on one month, ask for created_after set to the first moment of the month and created_before set to the first moment of the next one, both in your own time zone. A lead created exactly at midnight belongs to the new month only, so back-to-back months never count a lead twice. For September in Sydney that is created_after=2026-09-01T00:00:00%2B10:00&created_before=2026-10-01T00:00:00%2B10:00.
If you only need counts and attribution, add include_person=false&include_fields=false. Your system then never receives the lead's contact details, so there is nothing personal to store or secure. The source, tribe, form and tracking parameters still come back.
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. |
Reading the source of a lead
Each lead carries two kinds of source. calculated_source is worked out by Gorilla Dash from the tracking parameters, and is always exactly one of these values:
Paid SearchEmailPaid SocialLLM ModelGoogle My BusinessOrganic SearchOrganic SocialReferralDirect
It is neither first touch nor last touch. Gorilla Dash looks at every tracking parameter on the lead, from every visit it knows about, and picks the highest-ranked source it finds, in the order above. A lead that once arrived from a Google Ads click and later came back from a search result is Paid Search. The guide on lead source tracking lists the exact rule behind each value.
enquiry_sources is a list of the sources your own team has named under Enquiries > URL Sources, such as "Spring Sale". A lead can carry several of them, or none.
Both can change after a lead arrives. They are worked out again when the visitor's earlier visits to your website are added a few minutes after the lead is received, when the tracking parameters are replaced through PUT /enquiries/{id}, and when someone in your team selects Manually update all enquiry sources on the URL Sources screen. If you store the source, read it again when you refresh a month rather than keeping the value you saw on the day.
calculated_source. To reproduce a line exactly, open View Reports, choose Enquiry Datasets and read the parameters each dataset filters on, then apply the same rules to enquiry_url_parameters.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_afterset 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.
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.
