Merging contacts (now) creates a NEW ID???

[klkitchens]

Per: https://knowledge.hubspot.com/records/merge-records
when two contacts are merged, the data is combined into a NEW contact ID.  This is a (unwelcome) change from a few months ago, when merging B into A, moved the data from B into A and left the contact ID for A the same.

Is there a setting to overcome this new problematic change?  We keep our customers (HS Contacts) in synch via the contact ID which we store.  When an agent merges online our customer's HubSpotID is no longer valid.  If we update the customer record and push changes over to HS, then we'll detect the conflict and update our contact ID.  But we only do that when there is a change on our side... no reason to do it on a regular basis (we'd have to update ALL customers to reconnect.  It'd be a waste of API resources for sure to update everyone all the time.

[RubenBurdin · Accepted solution]

Hi @klkitchens , you’re reading it correctly. HubSpot changed merge behavior so the result of a merge can be a brand-new record with a new ID, and there’s no setting to force “keep the primary ID” like before. HubSpot calls this out in their developer changelog, and it applies regardless of whether the merge happened via API or in the UI (https://developers.hubspot.com/changelog/updated-merge-functionality-for-contacts-and-companies )

The good news is you don’t have to re-sync your entire database to survive it. Two patterns usually work well. First, treat HubSpot IDs as mutable and anchor your sync on a stable external key (your internal customer ID) stored on the contact in a custom property.

When you do need to write to HubSpot, look up the contact by that external key (or email, if it’s guaranteed unique) and then update by the current HubSpot ID. That keeps you from being “stuck” with a dead ID after a UI merge.

Second, if you want to catch UI merges proactively without waiting for a change on your side, subscribe to merge events via webhooks. HubSpot’s webhook payload includes primaryObjectId, mergedObjectIds, and sometimes newObjectId, which is exactly the mapping you need to update your local reference immediately (https://developers.hubspot.com/docs/api-reference/webhooks-webhooks-v3/guide )

Small disclaimer since I’m close to this: I work at Stacksync, and this is one of the cases it handles well, because it can keep an external ID as the “source of truth” and automatically remap HubSpot IDs when merges happen.

[klkitchens]

Thanks... I'll check that out.  Somehow some impersonator accepted your answer as the solution -- not sure how someone besides me can do that.  Very weird.  If it works, then I'll decide whether to mark it appropriately.

[SealaB]

Hi there, @klkitchens!
 

HubSpot has updated merge behavior to standardize how merges work across objects, and there isn’t a setting to restore the previous ‘keep primary ID’ behavior, but I will tag in some experts to see if they have any other strategies for this: @Bortami and @ChrisoKlepke - any suggestions on how to handle this implementation moving forward?

For supported endpoints, if you use a merged (old) ID, HubSpot will apply the operation to the current record. For basic updates specifically, you can use IDs stored in hs_merged_object_ids to update the current record.

I might suggest the following:

Check: Does Returned_ID == Requested_ID?

If No: Update your local database to replace the previous ID with the new ID.

This would allow you to update your records passively only when that specific customer is synced, rather than running a massive batch job.
 

You can also audit these changes by checking the property hs_merged_object_ids, which contains a list of all historical IDs that have been merged into the current record. Hope this helps!

[klkitchens]

Thanks, but this is not about the API merging... this is about the UI merges which break the back-end association by assigning a new number.

Obviously with the API, getting back a different ID would result in an update to our data association.