Bullhorn REST API configuration

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

Moderators: StaffingSupport, s.emmons, BullhornSupport

Post Reply
Posts: 1
Joined: Wed Dec 16, 2020 11:06 pm

Bullhorn REST API configuration

Post by gpasupathy »

I am trying to configure the Bullhorn Rest API outlined here (http://bullhorn.github.io/Getting-Started-with-REST/) for Shazamme.com

In trying to configure this using the standard OAuth 2.0 Protocol with either Postman or Insomnia, if I do each call individually I am able to get the results as demonstrated, but it seems to not follow the standard implementation for Oauth 2.0.

I also noticed that in the Auth call you have to pass the user name and password, which I think defeats the purpose of utilizing OAuth since then we would be storing the credentials. Do you support an alternative credential flow for system-level authentication?

Issues encountered:
• Documentation The documentation seems to suggest that parameters (e.g., client credentials) should be appended to the query string, contrary to the OAuth standard. However, in practice, it seems that parameters can be posted in the body as application/x-www-form-urlencoded.
• Access Token in query string It appears from our testing that the access token must be included in the query string rather than a header, e.g. Authorization: Bearer {access_token}, as described by the standard.
• Single-use access token It appears that the access token is single-use. Specifically, once exchanged for a session token, the access token cannot be used again. This is atypical. Access tokens have a lifetime (expires_in) and can be used to access the resource server any number of times within that lifetime.
• Stateful sessions It appears that OAuth is simply used to initialize a stateful session. As described, the access token is exchanged for a session token. The session token is then used to access resources. A defining characteristic of REST web services is that they are stateless.

This is not a RESTful web service. It is not secured with OAuth. It really seems like a SOAP API has been wrapped in a pseudo-REST API with an OAuth-like handshake inserted into the authentication process.

Based on the use case that the team has is there another form of authentication for the web service that can be triggered for a service, maybe a client credential flow (https://auth0.com/docs/flows/client-credentials-flow)?
Posts: 14
Joined: Fri Apr 10, 2020 11:02 am

Re: Bullhorn REST API configuration

Post by tluczak »

Hi there,

I can confirm that we do require OAuth and system level access is not allowed.

There are a few different ways of authenticating. One is REST-backed custom components: http://bullhorn.github.io/REST-Backed-C ... omponents/.

Also, in your Login call, if you don't want to store the username/password you can have a user enter their credentials and that will start an API session against their user account. That would look something like this: https://auth.bullhornstaffing.com/oauth ... tion=Login.

Please let me know if you have specific calls that are generating errors and I can look into those.
Post Reply