Data not appearing in ecommerce bridge and lots of sync errors

[j_j]

Hi,

For a year we've had perfect order data in the ecommerce bridge v2, which we sync from our ecommerce store. All orders sequential and all data such as line line items, orders, products and contacts working.

Then we wanted to add two new fields to our system. We created the fields in Hubspot and altered our mappings file to refer to them. At that exact same point, the system went awry. Now deals are missing and no longer arrive in sequential order. Some deals never get in to the system. Some work perfectly, but we're at reduced performance and nothing like the experience we used to have. Too much of a coincidence but the mapping update was the only think altered.

Why would adding two text fields cause so many issues? We have changed no other code.

If we log the API calls, we can see lots of sync errors, such as:

{"status":"error","message":"No sync messages found for LINE_ITEM 1254673 in Our Store","correlationId":"ab6314a7-1639-497a-9d1f-d0807d01663f"}

and other object types. Our data is fine, our JSON payloads are fine. 

We do not want to change our code if it has been working so well. We also reverted back to our old mappings and still no change in behaviour.

We were earlier told that our problem was caused by us not using the hubspotId's in our associations, but this is wrong. We can use any ID we like just as long as it is correct and unique. The ID's come from our ecommerce system and so are all correctly "joined". Also, using hubspotID's would mean even more API calls, as an object ID is not returned in the HTTP PUT when creating the object and one has to call a sync with the API to get the hubspotId value.

What to do? And how to debug? Advice appreciated.

[j_j · Accepted solution]

The three second delay did not work either, alas. However, we found a solution.

We've had to resort to using a polling/queueing system.  We have a scheduled task that picks up deals to process every 5 minutes, and we keep track of the deal, contact, product and line_item that pass/fail. If one or more fails we flag it and then the item stays in the queue until it is processed again. Once all 4 object payloads are accepted, the record (an order in our database in this case) gets removed from the queue. We use the sync test endpoint to check each JSON payload after it it PUT to the server.

One potential bug in the API to be aware about. The sync test endpoint returns a "200 OK" when the payload has been accepted, but sometimes the hubspotId for the object is set to "null". If it's null then the item will still not be sync'd to Hubspot and the data will be missing. In my mind the API should return a 400 (error) status in both cases. That one tripped me up for a good few hours, but once I looked for both conditions (400 status OR null hubspotId) to detect a payload sync error, the process became reliable. We now have sequential orders back again in Hubspot. Sometimes the API will reject a payload 3 or 4 times, but most of the time it works with two attempts. Single success attempts for four object payloads are a rarity for us. Sometimes the null objectId will fix itself within a few minutes, but sometimes they never get fixed and the objectId remains unallocated.

Still no idea why this has all happened now, but my guess is that the API has either become very slow, or is now rate limiting more agressively (or both).

Hope this helps someone. It worked for us. Hubspot - make your API faster! 

[j_j]

The three second delay did not work either, alas. We still have missing deals ☹️ The problem only occured after re-syncing our mappings JSON file. We've reverted that and the issue remains. Open to suggestions - the API just does not work reliably for us any longer. If we check the USPERTS with a sync, we see:

{"status":"error","message":"No sync messages found for DEAL 1234 in Our Store","correlationId":"826babf6-1bf3-4b1d-9431-a2e24c52a731"}

Funny thing is that some deals with errors still get in to the system, and some do not. How to debug that? Is there are more detailed way to get the error for a particular object?

Finally, can the payload for the UPSERT contain all of the objects together in one JSON structure?

[j_j]

Well the 2 second delay did not help, I've increased to 3 now.

[zaklein]

Hi @j_j 

As you're already aware, HubSpot's Ecommerce Bridge API uses a concept of an externalObjectId, which enables integrators to use unique record identifiers from external systems to populate HubSpot with ecommerce data. One of the advantages of taking this approach is avoiding the requirement of using HubSpot internal IDs to keep your e-commerce data up to date in HubSpot.

In general, the approach you've outlined to handling the Ecommerce Bridge makes sense. You mention that some record associations fail to materialise in your HubSpot portal. I've encountered similar problems in the past -- it could be due to a known race condition. Long story short, try inserting short pauses (say 3 seconds, assuming the integration with HubSpot is decoupled from any time-critical process, e.g. website page load) between related calls to Ecommerce Bridge API. For example, upsert Contact, upsert Product, pause 3 seconds, upsert Deal with Contact association, pause 3 seconds, upsert Line Item with Deal association. This approach typically results in better coverage of record associations when working with Ecommerce Bridge.

For your second question, that's correct. The Ecommerce Bridge API is designed so you can use your own record IDs from an external system. Using the HubSpot IDs you retrieve from the check sync status endpoint won't work with Ecommerce Bridge API. That being said, this endpoint is very useful in terms of retrieving (and then storing externally) the internal HubSpot record IDs and also for troubleshooting / error handling.

If you could safely share (please be sure to redact any sensitive / personally identifiable data) a few examples of the externalObjectIds and/or the entire JSON request bodies that are failing (1 per object type), this might help shine some light on any additional problems with your setup.

All the best,

Zach

[j_j]

Hi,

Thanks for the reply. I've heard about the race condition before, and we have 1 second delays inbetween, but we've not ever suffered from any issues up to now. I am loathed to change our code again (but agree we might have to if no other solution presents itself). The whole problem is just too coinidental to the change of mappings (adding the two text fields). Perfect data, change mappings, stops working.

One big issue with the ecommerce API is the payloads. The payload should be possible to add with one JSON structure. Sending 4 API calls seems wasteful. If we could put CONTACT, DEAL, PRODUCT and LINE_ITEM in one JSON structure it would be great, but we've tried and it does not work and support told us we need separate calls. That would also proably deal with the race condition you mention.

I will try increasing the delays, but the API calls are in a customer-facing page, so more delays for them. I can restructure that if it works however. Pauses also sound rather "hackish".

I'll let you know.

[dennisedson]

@zaklein , @RMones  would either of you be able to help @j_j  here 🙏