/search/ClientContact endpoint can return count lower than requested count in the middle of paging

Forum for users and developers of Bullhorn's API service.

Moderators: StaffingSupport, s.emmons, BullhornSupport

Post Reply
woutdegeyter
User
Posts: 8
Joined: Fri Nov 09, 2018 7:08 am

/search/ClientContact endpoint can return count lower than requested count in the middle of paging

Post by woutdegeyter »

Hi,

One of our common end users reached out to us with a problem. It turns out that we were not syncing all his Bullhorn contacts.

We investigated this in depth and it turns out that the issue is that your API returns us resource pages with a size lower than the requested one, whilst there are in fact more pages.
As such our paging mechanism believes that we are at the end of the paging as less resources are returned than we requested (so assuming there are no more resources).

To be a bit more technical, we are doing a request to the /search/ClientContact endpoint with the following parameters:
{
"sort": "-dateLastModified",
"start": "...",
"version": "2.0",
"showEditable": "true",
"fields": "id, dateLastModified",
"count": "50",
"query": "id[0 TO *] AND isDeleted:false",
"showReadOnly": "true"
}
Your API then returns us the data, together with the following paging parameters: total, start and count. What we saw is that:
- the returned count was lower than the requested count (which is set to 50 by us standardly)
- the total was higher than the value of start + count
This implies that there are in fact more pages, however we still got back less than 50 resources on the page. We confirmed that the next page indeed contained more resources.

We were not able to reproduce the issue on our own test account, but were able to reproduce it consistently for the user on the following API domain: https://rest30.bullhornstaffing.com/res ... es/47o92p/. It was somewhere around page 22 or 23, our developer believes. Hope this helps.

We are implementing a workaround on our side that relies on the "total" page metadata returned when doing the "initial sync" (getting all resources), but we cannot use this for the "incremental sync" (getting only the recently updated resources by sorting them descendingly by updated time) as we don't need to fetch all the resources in the latter case. There we'll see to find another workaround.
But still it would be very useful if you could look into this as it could have other bad side effects.

Could you please let me know the result of your investigation?

Thanks in advance.
Kind regards,
Wout

Post Reply