Practical automation · 4 min read
Connect website leads to HubSpot without losing the history
A new website request should add to the customer history, not wipe it out. Decide how to match contacts, save each request, and handle failed deliveries.
Someone asks for an estimate on your website. Your team opens HubSpot and finds a new contact with none of the earlier calls, or an existing contact whose useful details have been replaced by a short form. The connection moved the data, but it made the next conversation harder. Start by deciding what identifies the person, what belongs to this request, and what the website is allowed to change.
What to take away
- A person and a request are different records. One customer can ask for help more than once.
- Save the link between your customer record and the HubSpot contact once you have confirmed the match.
- Test repeat submissions, changed email addresses, and failed deliveries before handing the connection to your team.
Keep the person and the request separate
Consider a hypothetical body shop. A returning customer asks about a dent on a second car. Their name and phone number belong to the contact. The car, damage description, photos, and requested work belong to the new estimate request. Replacing the first request with the second loses useful history; creating a second person makes that history harder to find.
Choose where each request will live before connecting the form. That might be a deal, another record suited to your HubSpot setup, or your own job system linked to the contact. HubSpot supports associations between contacts and records or activities. The right choice depends on how your team works and which features your account has.
Sources: HubSpot: Contacts API
Agree on what counts as the same contact
HubSpot lets an integration retrieve a contact by record ID or email address. Its batch upsert operation can create or update contacts using email or a custom unique identifier. Upsert means updating a match or creating a record when there is no match.
For a connected customer system, we recommend saving the confirmed HubSpot record ID against that system's customer ID. An email address can change. A shared address can also represent more than one person. Send uncertain matches to someone who can check them instead of merging records based on a similar name.
There is a useful implementation detail to check: HubSpot does not support partial contact upserts when email is the identifier. Its documentation directs partial upserts to a custom unique identifier. Check the update method against the fields you actually intend to change.
Sources: HubSpot: Contacts API
Protect the work your team has already done
Make a short field map with your team. For each value, name the system that owns it and decide what happens when the systems disagree. The website might supply the latest request details while HubSpot owns the assigned salesperson and sales stage.
Treat a blank form field as a decision, not an instruction to erase data. Do not let a new request reset staff notes or enroll an existing customer in a campaign by accident. Keep marketing preferences separate from the fact that someone asked for an estimate.
Run a sample through the connection with a salesperson watching. They should be able to find the new request, see the earlier history, and tell who needs to act next without opening an integration log.
Make a repeated delivery safe
Save each website request with its own ID before sending it to the CRM. If delivery times out, use that same ID when checking or retrying the work. The body shop should see one estimate request even if the connection tried to send it twice. A genuinely new estimate request should still be saved, even when it comes from the same customer.
If your integration also receives HubSpot webhooks, account for repeat notifications. HubSpot retries failed deliveries, and its webhook event ID is not guaranteed to be unique. Do not rely on that field alone to decide whether a business action has already happened.
Keep a record of what was accepted, what failed, and what needs a person to check. Test a failure after the CRM has accepted a request but before your site receives the response. That uncertain outcome is where a blind retry can repeat work.
Sources: HubSpot: Webhooks API guide
Keep this handy
Your pre-project checklist
- Choose where a person and each separate request will live.
- Write down the matching rule and the cases that need a person to check.
- Name the owner of each synced field and define what blank values mean.
- Test an existing customer, a new customer, and a customer with a changed email address.
- Send the same request twice, then send a genuinely new request from the same person.
- Check what happens when delivery fails after the CRM has accepted the request.
- Ask the person doing follow-up to find the request and explain their next step.
Prefer to write it down? Tell us about your project. No portal account required.
These examples explain how we would approach the work. They are not client results. How we write our guides or send a correction.