Pushing an enquiry (a lead) into Gorilla Dash

This is the endpoint most integrations are built around. Send a lead to POST https://api.gorilladash.com/api/v1/enquiries and Gorilla Dash creates an enquiry, matches or creates the contact behind it, routes it to a tribe, records where it came from, and notifies whoever should know.

It is the same path your Gorilla Dash website forms use, so a lead pushed through the API is indistinguishable from one submitted on your own site — same automations, same reporting, same notifications.

Before your first call

Get your API key and access token from Organisation Settings, then Connections.
Pick the enquiry form the lead should arrive on, and note its slug. Call GET /enquiry-forms to list them.
Make sure your organisation has a default website set. Without one, every push fails with a 404 — see the traps below.

The smallest call that works

Three fields are required: the form slug, a first name and an email address.

{"enquiry_form_slug":"contact-us","first_name":"Sam","email":"sam@example.com"}

That succeeds with a 201 and a body of {"status":201,"success":true,"data":{"id":12345,"message":"Enquiry created successfully."}}. Read the id from data.id and keep it — it is what you use to update the enquiry later, and what you match on if you sync enquiries back out.

Who the lead is

Field	Required	Notes
`first_name`	Yes	Part of how the contact is matched. Be consistent about capitalisation.
`last_name`	No	Also part of the match. Omitting it on some submissions and not others creates two contacts.
`email`	Yes	Must be a valid address. The strongest part of the match.
`mobile`	No	Any readable format. Gorilla Dash parses it and stores it in international form.
`business_name`	No	Also part of the match. See the person matching guide before you decide to send it.

READ THIS ONE NEXT

How those five fields combine to find or create a contact has real consequences — duplicate contacts, lost phone numbers, leads attached to the wrong person. The guide "How Gorilla Dash matches an enquiry to a person" explains it in full, and it is worth ten minutes before you go live.

Where the lead is

Field	Notes
`address_1`, `address_2`	Street address.
`locality`	Suburb, town or city.
`state`	State, province or region.
`postal_code`	Postcode or ZIP.
`country`	Country.
`latitude`, `longitude`	Numbers, not strings. Used only for routing to a tribe.

The address does double duty: it is saved on the contact, and it is used to work out which tribe should get the lead when you have not named one.

How the lead gets routed to a tribe

Gorilla Dash works down this list and stops at the first thing that produces a tribe.

You are using a tribe key. The lead goes to that tribe, and tribe_slug is ignored entirely.
You sent tribe_slug and it matches a tribe in your organisation. This is the reliable way to route.
You sent tribe_name and it matches a tribe name exactly.
You sent an address or coordinates. Gorilla Dash geocodes it and picks the nearest tribe, optionally narrowed by tribe_name.
Nothing matched. The enquiry is created with no tribe.

A LEAD WITH NO TRIBE IS STILL A LEAD

If the address will not geocode — someone typed "N/A", or a place that does not exist — Gorilla Dash does not reject the submission. It saves the enquiry with no tribe attached, because losing the lead is worse. Those show up unassigned in your enquiry list, so watch for them: a run of unassigned leads usually means your routing field is wrong.

Send tribe_slug wherever you can. Name matching is exact, so a stray space or a renamed tribe silently drops you to the geographic search, and the geographic search depends on an address the lead typed.

What the lead said

Everything beyond name, email and address goes in fields — an array of {"name":"...","value":"..."} pairs. The names should match the fields on the enquiry form you are posting to; call GET /enquiry-forms/{slug} to see them.

"fields":[{"name":"Message","value":"Please call me"},{"name":"Service","value":"Signage"}]

Two field names are special. A field called Message is treated as the enquiry body throughout Gorilla Dash. A field with a phone-like label — Phone, Mobile, Contact Number and similar — is used as the contact's number when you have not sent mobile at the top level.

That fallback only matches the enquirer's own number. A field named "Business Phone" or "Agent Phone" is left alone, which is what you want.

A NAME THE FORM DOES NOT HAVE IS SILENTLY DROPPED

Every entry in fields is checked against the enquiry form's own field names, ignoring case and surrounding spaces. Anything that matches is stored under the form's spelling; anything that matches nothing is discarded without an error, and an enquiry with no form at all loses the whole array. You still get a 201, so the only way to notice is that the answer never appears. Read GET /enquiry-forms/{slug} once and map your names onto it.

Where the lead came from

Send tracking_data to record the campaign, ad click or referrer behind the lead. Gorilla Dash turns it into a lead source automatically.

"tracking_data":[{"parameter":"utm_source","value":"google","path":"/quote"},{"parameter":"gclid","value":"Cj0KC..."}]

This is the difference between a report that says every lead is "Direct" and one that tells you which campaign paid for itself. The guide "Tracking where your leads come from" covers it properly — what to send, what Gorilla Dash does with it, and what each source name means.

The remaining fields

Field	What it does
`enquiry_form_slug`	Required. Which form the lead arrives on. Must exist in your organisation.
`tribe_slug`	Route the lead to this tribe. Ignored on a tribe key.
`tribe_name`	Route by exact tribe name. A weaker fallback than the slug.
`notify`	Defaults to `true`. Send `false` to load a lead silently with no emails or texts.
`ip`	The visitor's IP address. Also part of duplicate detection.
`client_site_visitor_id`	Your own visitor identifier, if you track one.
`files`	Attachments. Each entry needs a `filename` plus a `file` that is either a public URL or base64 data.

IMPORTING HISTORY? TURN NOTIFICATIONS OFF

Send "notify": false when you are backfilling old leads. Without it, a one-off import of two years of history emails and texts your whole network about leads from 2024.

What happens after it lands

The contact is matched or created, and linked to the tribe.
On a website-style enquiry the contact is marked as an active lead for that tribe.
The enquiry is checked against your spam list and flagged if the address or domain is blocked.
The lead source is calculated from your tracking data, along with first touch, last touch and how long the visitor took to enquire, and any named sources you have configured under URL Sources are attached. This happens before the response comes back.
The notification text goes out straight away, unless you sent "notify": false or the enquiry was flagged as spam.
The notification email goes out on a schedule, not immediately — see below.
Background work runs: AI enrichment, contact classification, and any connected system that mirrors your leads.

The response comes back as soon as the enquiry is saved. The AI enrichment and the connected-system mirroring run in the background afterwards, so do not expect the AI summary to be readable the instant you get your 201.

THE NOTIFICATION EMAIL IS NOT IMMEDIATE

The text message is sent as the enquiry is saved, but the email is picked up by a scheduled sweep that deliberately waits for the AI summary: about two minutes once the summary is ready, and up to twenty when it never arrives. If you send a test lead and check your inbox thirty seconds later, nothing is wrong — give it twenty minutes before you report it.

Duplicate submissions

Gorilla Dash recognises a repeat of a submission it has already taken. If the form, organisation, IP, tribe, name, email, Message and all custom field values are identical to an existing enquiry, no second enquiry is created — the API answers 201 and hands back the original enquiry's id.

THIS IS WHY YOUR SECOND TEST DID NOT APPEAR

Sending the same test payload twice gives you two 201s and one enquiry. Change something real between tests — the email address is easiest. It also means a network timeout is safe to retry: the retry cannot create a duplicate, and it returns the id of the enquiry that did land.

Note that tracking_data is not part of that comparison. Two otherwise identical submissions with different campaign data are still one enquiry.

When it fails

Response	Cause
401	Key or access token missing, mismatched or wrong.
403	The RESTful API is switched off for your organisation.
404	`enquiry_form_slug` does not match a form in your organisation, your organisation has no default website, or the save failed on our end.
422	Missing `first_name` or `email`, an invalid email, `latitude`/`longitude` sent as strings, or a malformed `tracking_data` row.
429	Over the rate limit. Back off and retry.

THE 404 THAT LOOKS LIKE A BUG

A 404 on this endpoint has three completely different causes, and the response does not distinguish them. Check your form slug first. Next, the organisation may have no default website set — an admin needs to mark one as default before any lead can be pushed. Third, any internal failure while saving the enquiry is also reported as a 404, so if both of those check out it is our end: send us the exact time you called and we will read it out of the log.

Going live checklist

Push one real-looking lead and find it in the Gorilla Dash enquiry list.
Confirm it landed on the right tribe, and that the contact looks right.
Confirm the notification reached whoever should have got it.
Confirm the lead source is what you expected, not "Direct".
Vary the email address between tests so duplicate detection does not mislead you.
Handle 201 as success, 422 as "fix and do not retry", and 429 or 500 as "wait and retry".
Log the returned enquiry id against your own record, so you can trace any lead end to end.