We've noticed that this API is returning inconsistent data which appears to be caused by indexing delays. We update 25 contacts in Hubspot using the bulk edit functionality
We make a request and the most recently modified contact has a timestamp of 1592488442291, the next contact has a lastmodifieddate of 1592488441522 This seems correct and all is good in the world. However 5 minutes later we make the same request and the most recently modified contact has a timestamp of 1592488442291 which is the same as before. However this contact is a new one and the 2nd contact in the list is now the first one we saw on our previous request. Additionally there are new contacts showing in the list with older timestamps
This appears to make the endpoint unusable as you don't know if you're actually getting all updates. Is this just temporary and possibly a bug on Hubspot's end? Is there an alternative method for polling Hubspot?
At the moment, the Get recently updated and created contacts endpoint reads from ElasticSearch to find contacts with a recent last-modified-date, and returns them in order of their last-modified-date (most recent first).
In your case, it looks like contact ID 3051's update was indexed into ElasticSearch a little bit delayed, just after your team had done the first query but before your team had repeated it the second time.
While we aim for a <5s index time from the update, the bulk updates may sometime take longer.
On my end, I'm unable to reproduce this behavior in my own portal.
I was able to see the same contact returned as the first in the list when using the Get recently updated and created contacts back to back (5mins delay each time, just like your test).
In order for me to further troubleshoot this, could you share with me the following:
1. The portal ID in question.
2. The first return body and the second return body (after 5 mins) that is showing the differences.
At the moment, the Get recently updated and created contacts endpoint reads from ElasticSearch to find contacts with a recent last-modified-date, and returns them in order of their last-modified-date (most recent first).
In your case, it looks like contact ID 3051's update was indexed into ElasticSearch a little bit delayed, just after your team had done the first query but before your team had repeated it the second time.
While we aim for a <5s index time from the update, the bulk updates may sometime take longer.
I'm now able to reproduce this issue and my current hypothesis is that because the timestamp is the same even to the seconds, that is why there's some change in the position.
Having said that, I do notice that the miliseconds timestamp are all unique and so I'd expect the return response result to be the same. For this case, I'll have to check in with the internal team and I'll keep you posted here.
Jun 24, 20208:51 AM - edited Jun 24, 20208:58 AM
Member
Get recently modified or created contacts bug - Indexing delay
SOLVE
Hi Wendy,
Thank you for your response. I've been able to reproduce it pretty often and the delays sometimes differ.
I edited 10 contacts' state/region property in Hubspot by selecting 10 contacts then clicking edit from the main list/view all contacts page
I then made an API call to the get recently modified contactsAPI with query param count=10. On this request I get back 10 last modified contacts. Notice that the first one (the most recent) has a timestamp of 1593001672723
However this time the order is 2751 2851 2801 2901 3051 3401 2651 2401 2451 1751
3501 was added retroactively.
The only way we know to solve for this essentially processes all contacts twice using this endpoint which uses a lot of our API requests and makes this process very inefficient. Our hope is that Hubspot can fix this issue so that contacts are not added to this list retroactively.
The maximum delay we've seen is 22 minutes but it is hard to say that the delay won't ever be longer than that.
For more context we are trying to capture any contacts that are updated in the Hubspot system. The issue we have with webhooks is that we can't support all of our customers custom fields. We also looked at using the new V3 Search API but also found the same delay issues with that API in addition to some other weird behaviors.