API
Enquiry forms: finding the slug and the fields
GET /enquiry-forms lists your forms and their slugs, and GET /enquiry-forms/{slug} returns the fields one form expects — the discovery step before you can push a lead.
Last updated September 2, 2026
Every lead you push has to name an enquiry form, and it names it by slug. These two endpoints are how you find that slug, and how you find out which custom fields the form expects.
Listing your forms
GET https://api.gorilladash.com/api/v1/enquiry-forms
| Parameter | Notes |
|---|---|
page | Page number, from 1. |
results_per_page | Up to 1000. Defaults to 100. |
updated_after | Only forms changed since this timestamp. Send a full ISO 8601 value with an offset. |
Each entry returns id, organisation_id, name, slug, created_at, updated_at and record_updated_at. Forms come back ordered by name.
A tribe key sees its parent organisation's forms, not a narrower set — enquiry forms belong to the organisation, and any tribe can be sent a lead on any of them.
One form and its fields
GET https://api.gorilladash.com/api/v1/enquiry-forms/contact-us
Returns the form plus a fields array, each entry having a name, a type and a default value. The name is exactly what you put in the fields array when you push a lead.
The list endpoint deliberately does not include field definitions. Call the single-form endpoint for those.
Using it in an integration
- Call the list once while you are building, and hard-code the slug you are sending to. Slugs do not change on their own.
- Call the single-form endpoint to confirm the field names, and map your own field names onto them.
- If you offer customers a choice of form — an automation tool, for example — call the list at configuration time and let them pick.
Caching
Both endpoints are cached and send an ETag. A form definition changes rarely, so this is one of the endpoints where a conditional request saves the most — and where an edit can take a few minutes to appear.
