API
Updating an enquiry after it has been created
PUT /enquiries/{id} lets you add or correct custom fields and replace tracking data on a lead you already pushed, which recalculates its source and attribution.
Last updated September 2, 2026
Sometimes you learn something about a lead after you have sent it — a qualification answer arrives late, or the campaign data was missing on the original push. PUT https://api.gorilladash.com/api/v1/enquiries/{id} lets you fill that in without creating a second lead.
The {id} is the enquiry id that POST /enquiries returned. PATCH works identically.
What you can change
Two things, and only two. Send at least one of them.
| Field | Behaviour |
|---|---|
fields | Merged by name. Fields you name are added or overwritten; fields already on the enquiry that you do not mention are left alone. |
tracking_data | Replaces everything. The whole tracking set is swapped for what you send, and the source is recalculated. |
GET /enquiries and send the whole thing back with your addition.You cannot change the contact, the tribe, the form or the created date through this endpoint. Those are fixed at creation. Correcting a contact detail is done in Gorilla Dash itself.
Adding a field
{"fields":[{"name":"Budget","value":"5000-10000"},{"name":"Qualified","value":"yes"}]}
Values must be strings — send "5000", not 5000. An explicit null is accepted and stored as an empty value, which is how you clear a field rather than delete it.
Correcting attribution
{"tracking_data":[{"parameter":"utm_source","value":"google"},{"parameter":"utm_medium","value":"cpc"},{"parameter":"gclid","value":"Cj0KCQ..."}]}
Replacing the tracking data re-runs the whole attribution calculation: the calculated source, first touch, last touch, time to enquiry, and the named sources from your URL Sources configuration. It is the supported way to repair a batch of leads that arrived with no campaign data.
Each row takes the same keys as on the push: parameter, value, path and session_at, with the same timestamp checks applied.
Sending an empty tracking_data array clears the tracking set entirely. That is only accepted alongside a fields payload, so you cannot wipe attribution by accident with an otherwise empty request.
What comes back
A 201 with the full enquiry, in the same shape as GET /enquiries. That is deliberate: the enquiry form can rename or drop fields it does not recognise, and the response shows you what was actually stored rather than what you sent.
fields array, the form filtered it out. Compare the names against GET /enquiry-forms/{slug}.Errors
| Code | Cause |
|---|---|
| 404 | The enquiry does not exist, or it belongs to another organisation — or, on a tribe key, to another tribe. |
| 422 | Neither fields nor tracking_data was sent, a field value was not a string, or a tracking row had no parameter. |
| 403 | The RESTful API is switched off for your organisation. |
Retrying safely
The update is safe to repeat: sending the same payload twice leaves the same result. Internally the field write and the tracking write are separate steps, so a failure between them can leave the fields updated and the tracking not — simply send the whole request again.
An update also refreshes the enquiry's change timestamp, so anything polling GET /enquiries with updated_after will pick the lead up again. It does not re-send notifications.