Hello max_max_mir, I wanted to pass along what I believe needs to be done here. Can you try the below when bringing these back. This would be a GET. https://rest2.bullhornstaffing.com/rest-services/xxxxx/entity/Candidate/275166?fields=primarySkills&query={skill.id < 250}&BhRestToken=xxxxx Please let...

Hey Max, I spoke to our Engineering Team about this and have confirmed this is not a typo in the documentation. Even though there are a few different parameters to update when looking at the LoginRestrictions, this is looked at like it is all 1 field in the API. The CorporateUser structure is a litt...

Hey Max, If something specific comes up on it I will report it here but there is no specific reason that I know of other than it just being structured this way for the Note Entity. It is probably because the Note entity is a little more complex then the other main entities that have their own lists ...

Hello Max,
Yes you are correct here. The correct terminology should be something like Ternary here. I will bring this up with our documentation team and work on updating. Thank you for the notice here.

Hello,
This field is working as intended also. employmentPreference was built this way on purpose to return values in an array. The employeeType field is built the same way.

Hello,
These fields are meant to return that way when searching meta because they are read only and cannot be modified via the API. This is why the maxLength returns as 0.

Hello, The sort reference field should be noteID for this to work. I did a call like below and could returned sorted results. https://rest3.bullhornstaffing.com/rest-services/xxxxx/search/Note?query=isDeleted:false AND dateAdded:[1361635821000 TO *]&fields=id&count=500&start=0&useV2=true&BhRestToken...

Hello,
The reason why this is referenced as SCALAR is because all of the fields are lumped as 1 when getting pulled from the API. By Design it functions as 1 field even though you have to set a few values within the Login Restrictions data type.

Hey Dave,
Yes you can get this information no problem. I would just have the Bullhorn client submit a Bullhorn ticket requesting this as we need authorization from the client to provide that information to you.

Hello, Can you try capitalizing the Task you have within the request URL? I would also suggest removing the client contact ID because once the task is created you will want to perform a PUT entity to associate the task to a particular record. For example it would look something like the below: https...

Hello, Are you currently working with a company that uses Bullhorn and trying to test the API within their environment? Can you let me know who the company is and what environment you are working in? If it is a test environment, you might just have to change the endpoint you are using in corresponde...