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.
Is there a reason why we're seeing duplicates across pages in calls to /contacts/v1/search/query?
@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:
Is there a reason why we're seeing duplicates across pages in calls to /contacts/v1/search/query?
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.
Is there a reason why we're seeing duplicates across pages in calls to /contacts/v1/search/query?
@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.