Is there a reason why we're seeing duplicates across pages in calls to /contacts/v1/search/query?

contacts

#1

For one of our clients we’re seeing the same contacts returned on multiple pages. For an example see:

There are 16 duplicate contacts across those two pages:

The entries are almost entirely, but not exactly, the same. The only differences are in the profile-token and profile-url. See the attached image.

Also, at least for some of these, the two profile URLs appear to resolve to exactly the same HTML.

This appears to us to be a defect in the API when paging large numbers of contacts. We also don’t see a practical solution to this that is scalable and doesn’t require us to store an indeterminate number of contacts in memory.

This is an urgent issue for our customer. Any help we can get with this would be greatly appreciated.


#2

@Rick_Rothenberg can you tell me more about the data you’re trying to get out of HubSpot? That endpoint isn’t intended to be used with an empty q= parameter, and if you’re just looking for all contacts you should be using the endpoint documented here:


#3

Our code implements a general purpose, normalized REST API to Hubspot as well as a number of other vendors. Our endpoint to get contacts allows the caller to optionally specify search criteria. The most straightforward way to do this for us was to use only the search/query endpoint and pass nothing for the q query parameter when nothing was passed to us. Nothing in the documentation suggests that it is illegal to pass an empty search string and the behavior we saw seemed to indicate that worked.

Good point though. We’ll check to see if this problem goes away when using the /contacts/v1/lists/all/contacts/all endpoint for the specific case where we don’t have any search terms.


#4

@dadams, it does seem though (IMHO) that if this case isn’t supported it would be better for the API to reject an empty search term rather than fail quietly.


#5

Switching to /contacts/v1/lists/all/contacts/all did seem to fix the problem. Thanks.