How Gorilla Dash matches an enquiry to a person

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

EMAIL ALONE IS NOT THE MATCH

This is the part that surprises everyone. The same email address with a different spelling of the name, or with a business name on one submission and not the other, produces a second contact. If you are seeing duplicates, this is almost always why.

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.

THE PRACTICAL TEST

Send the same person twice from your integration, changing nothing. If you get one contact with two enquiries, your normalisation is right. If you get two contacts, something in your payload is varying — usually whitespace.

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 mobile field, 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.

A NUMBER WITHOUT A COUNTRY CODE MAY NOT BE USABLE

"0412 345 678" can be stored but may not resolve to a real international number, and automations that text your leads will skip the contact. "+61412345678" always works. If your source stores local numbers, add the country code in your integration before you send.

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.