ECommerce Bridge - line items with the same integratorObjectId


I'm seeing some odd behavior around deleting/adding/updating line items that are attached to a deal using the Sync Messages API, and was hoping to get some clarification on if this behavior is intentional, or whether or not this is a bug.

The behavior has to do with deleting an associated line item from a deal, and then re-adding it to that same deal. For context, in this example we are using the Deals entities to represent (e-commerce) subscriptions, with the line items representing the products in that subscription. This can change any time the customer wants to modify their subscription.

So here's the scenario: User deletes product foo from their subscription, then changes their mind and re-adds product foo back to their subscription.

Deleting foo from the deal:

    "integratorObjectId": "376161:107",
    "action": "DELETE",
    "changeOccurredTimestamp": 1531850442256,
    "propertyNameToValues": {}

Re-adding foo to the deal:

    "integratorObjectId": "376161:107",
    "action": "UPSERT",
    "changeOccurredTimestamp": 1531850456725,
    "propertyNameToValues": {
      "associated_product_id": 107,
      "associated_order_id": 376161,
      "quantity": 1

What I'm seeing is the line item does not get re-added to the deal. The initial API request returns a success response, and the sync errors endpoint does not return any related errors. I suspect the reason has to do with the fact that I'm using the same integratorObjectId. In our system we don't actually have a unique identifier to represent these line items, so I used a combination of the order ID and the product ID.

Would this be considered expected behavior? Do I need to alter my implementation and assign these line items unique identifiers?



Just to clarify, when you send that first delete sync, it's against the LINE_ITEM endpoint, right?


@Sean_Duane Yes, /ecomm/v1/sync-messages/LINE_ITEM is the endpoint I am using for the sync messages above.


@Walter_Anderson Yeah that doesn't sound right then.

Sync messages will respect objects deleted outside of the sync (e.g. via the Hubpot UI or API), but it should be able to resync something that was deleted via sync.

I'll look into it tomorrow/early next week


Hey @Sean_Duane, just wanted to follow up and see what the status is on this issue.


@Sean_Duane any updates here?


@Walter_Anderson Hey, sorry for taking so long. I've been preoccupied with other items, so this will have to be a next week fix.


@Sean_Duane Thanks for the update, I'll keep an eye on this post.


@Walter_Anderson Finally getting to this.

I can confirm that objects deleted via sync are not able to be recreated via sync.

I have a plan to fix this.
This fix will maintain what I said before - Objects deleted outside of sync (via api, via ui) cannot be resynced until recreated (manually, via api)


@Walter_Anderson Well that was a fun fix!

Objects deleted via sync should now be able to be created anew via sync, moving forward, as of today.

Give it a shot and let me know if it works as expected?


I am having an issue with Products created using the Sync Messages API.

I deleted the products by hand within the HubSpot portal, and now I can not UPSERT a product using the same integratorObjectID from the previously deleted product via the Sync Messages API now.

I have verified this variable is the cause, because when I change integratorObjectID the product is created.


I understand what was stated above, about Sync respecting objects deleted manually, but is there a way to re-use the integratorObjectID from an object that was manually deleted?


Bumping this up for Tyler, please let us know if this is working as expected @Sean_Duane!


Currently, there is no way to "recover" an integratorObjectID except to recreate the deleted object.

I can definitely consider some workarounds at some point. Maybe you should be able to determine the internal hubspot ID? Maybe you should be able to say "force resync this" which creates a new object?