API
How Gorilla Dash matches an enquiry to a person
Exactly which fields decide whether an incoming lead joins an existing contact or creates a new one, why duplicates appear, and how to send data so they do not.
Last updated September 2, 2026
Every enquiry belongs to a person — a contact record. When a lead arrives, Gorilla Dash either attaches it to a contact it already holds or creates a new one. Which of those happens is decided by a fixed set of fields, and knowing them is the difference between a clean contact list and three copies of the same customer.
The matching rule
Gorilla Dash looks for an existing contact where all five of these are the same. Find one, and the enquiry joins it. Find none, and a new contact is created.
| Part of the match | Comes from |
|---|---|
| Organisation | Your API key. Contacts never match across organisations. |
| First name | first_name |
| Last name | last_name, or empty if you did not send one |
| Email address | email |
| Business name | business_name, or the value of a custom field called Business Name |
The comparison is exact. "Sam" and "sam" are different people. "Acme Pty Ltd" and "Acme Pty. Ltd." are different people. Leading or trailing spaces count.
What creates a duplicate
| First submission | Second submission | Result |
|---|---|---|
| Sam Green, sam@example.com | Sam Green, sam@example.com | One contact, two enquiries |
| Sam Green, sam@example.com | sam green, sam@example.com | Two contacts |
| Sam Green, sam@example.com | Sam, sam@example.com | Two contacts — last name differs |
| Sam Green, no business name | Sam Green, business name "Acme" | Two contacts |
| Sam Green, sam@example.com | Sam Green, s.green@example.com | Two contacts |
How to avoid them
- Normalise before you send. Trim spaces, and settle on one capitalisation — title case is the usual choice.
- Be consistent about
last_name. Always send it, or never send it. Alternating is what causes most duplicates. - Be consistent about
business_name. If your source only sometimes has it, consider not sending it at all rather than sending it half the time. - Lowercase email addresses on your side before sending.
- If one source of leads spells names differently from another, fix it in your integration rather than in Gorilla Dash afterwards.
What gets updated on a match
When a lead joins an existing contact, some fields are refreshed and others are deliberately left alone.
| Field | Behaviour on a repeat submission |
|---|---|
| Mobile number | Overwritten — but only if this submission carried one. A phone-less submission never wipes a number captured earlier. |
| Address | Overwritten, but only if this submission included address_1. Without it the whole address block is left untouched. |
| Name, email, business name | Unchanged by definition — they are the match, so they were already equal. |
| Contact categories | The enquiry form's categories are added. Existing categories are kept. |
| Tribe links | The routed tribe is added. Existing tribe links are kept. |
The mobile rule is worth reading twice. It is what stops a "download our brochure" form that asks for email only from erasing the phone number a customer gave you last week.
Where the phone number comes from
- The top-level
mobilefield, if you sent one. - Otherwise, a custom field with a phone-like label — Mobile, Phone, Phone Number, Telephone, Contact Number, Cell, Your Phone and a handful of close variants.
- Otherwise the contact keeps whatever number it already had.
The label match ignores case and surrounding spaces but is otherwise exact, and the list is deliberately narrow: a field called "Business Phone" or "Agent Phone" is never mistaken for the enquirer's own number.
Whatever the source, the number is parsed and stored in international form. If it cannot be parsed — no country code and no way to infer one — the raw text is kept for display but the contact has no usable number, which means text messages and phone automations skip them. Send numbers in full international form, starting with the plus sign, and this never bites you.
One person, one tribe
Gorilla Dash treats each contact as belonging to a single tribe, even though the underlying data can record more than one link. The API always returns exactly one tribe_id and tribe_slug per contact: their primary tribe if one is set, otherwise the earliest one they were linked to.
So pushing the same contact to a second tribe does not move them. It adds a link, and they keep reporting under the first. Do not design an integration that expects a contact to belong to several tribes at once.
New contact, or returning one?
Gorilla Dash records on each enquiry whether the contact behind it was created then and there or already existed, so your reporting can separate genuinely new leads from repeat enquiries by the same person. You will see that reflected in the enquiry reports rather than in the API payload.
Cleaning up duplicates you already have
Fix the integration first — otherwise you will tidy the contact list today and have new duplicates tomorrow. Re-sending a lead never merges anything: it simply matches one of the copies. Once your payload is consistent, talk to support about tidying the contacts already created, and say which fields were varying so the right copies are kept.