Token refresh issues

[connectorsTray]

Hi,

We've been facing issues refreshing tokens for your API for about a year now. We have a mutual customer whose Oauth app we are connecting with, and encountering failures for all users attempting to use the integration. We have ensured that they are only using this Oauth app with our platform, so there is just one login per user to the Oauth app, and that concurrent token refreshes are not allowed so that tokens are not expired. We have followed the guidance here: https://www.bullhorn.com/marketplace/wp ... tokens.pdf in creating our application, but we are constantly facing the error "OAuth token request error: This authentication can no longer be used (invalid refresh token). Please create a new one. - 400", when sending the refresh request to

https://auth-west9.bullhornstaffing.com/oauth/token
-H Content-Type application/x-www-form-urlencoded
-D grant_type: refresh_token
-D refresh_token: ...<redacted>
-D client_id: ...<redacted>
-D client_secret: ...<redacted>

We would appreciate some support in order to get this implementation stood up correctly!

[lciastko]

Hello!

At first glance, I am seeing that the REST Endpoint that you specified (auth-west9) is one that is used for our Non-production Environments.

To get the correct Endpoint, you can use the following link to associate an Endpoint to your Data Center.

http://bullhorn.github.io/Data-Center-URLs/

Additionally, do you require a constant connection to the API for your integration? Or is it only powered by User Activity? If you do require a constant connection, then you need an API Username and Password. Here, you can have complete control over re-authentication if there are ever any issues instead of relying on a user to have to log back in. If you do need an API Username and Password, this request needs to go through Bullhorn Support as this is more sensitive information that should not go through the Bullhorn API Support Forums.

Hopefully this helps,
Lindsay

[connectorsTray]

Thanks for your reply Lindsay,

I will verify with our customer that we are using the correct data centre. Do you have any documentation on using API Username + Password, is this separate to the Oauth mechanism? It would be great to understand what the flow would be for our Partner's users compared with currently where they just log in. We anticipate that it may be difficult for each of our Partner's users to request this API username + password if we understand correctly which is why Oauth may be preferable. Our use cases centre around realtime information retrieval from Bullhorn, it sounds like having a Constant Connection could be beneficial for our use case.

Let us know!

[lciastko]

Hey again!

A great place to get started would be or documentation here: http://bullhorn.github.io/Getting-Started-with-REST/

Right now, you're using the following query:

Code: Select all

GET https://auth.bullhornstaffing.com/oauth/authorize?client_id={client_id}&response_type=code&action=Login

To log in programatically you would use this API Request:

Code: Select all

GET https://auth.bullhornstaffing.com/oauth/authorize?client_id={client_id}&response_type=code&username={username}&password={password}&action=Login

When you use the above request, you need a username and password. Therefore, the user is prompted to provide it, but if you provide it in the request like the first URL, then it logs in for you.

I hope that this helps!
Lindsay

[connectorsTray]

Thanks Lindsay,

I can see the username and password in the documentation. In terms of refreshing the token, is there any difference between requesting the user to login through a modal vs collecting their username + password and sending those in the query string? I.e. does the request to refresh the token look different in either case? We're trying to understand why the actual refresh of the token is failing.

[lciastko]

There should not be a difference in terms of obtaining the Refresh Token. But if you are having an issue with getting the refresh token sporadically (i.e. after time has elapsed), then this may be one of the contributing factors.

Did you try to edit the Rest URL to accommodate your client specific Data Center and have any luck with this? This is a pretty common issue when it comes to Refresh Token issues.

Other reasons that the Refresh Token may not generate could be one of the following:
The refresh_token was sent through Bullhorn's API, but the response never made it back to you (something like a network error, latency, routing issues, firewall, etc). If you are using a user's session to authenticate and changes are made to that account that could impact obtaining the refresh_token
Lastly, Sharing the API Credentials across multiple API Applications will invalidate all tokens.

[connectorsTray]

We haven't been able to obtain the data centre specific URL for this app yet, perhaps you could help us out in obtaining it?

[lciastko]

Do you by chance know what Swimlane that you are on? Or could you perhaps you could provide me your general region?

If I were to make an assumption, I would say you would possibly be a part of the UK Swimlane - SL29.

Oddly enough, SL29 is not on the Data Center URL Page. I am assuming that these would be your REST URLs, but I am working to confirm this information:

• https://auth-emea.bullhornstaffing.com
  https://rest-emea.bullhornstaffing.com
  https://api-emea.bullhornstaffing.com

I will follow up once I receive confirmation. Additionally, I will be submitting a request on my end to have SL29 added to our documentation.

[connectorsTray]

Hi Lindsay,

As we don't manage this account directly I don't know which region or swimlane this app is in. Would you be able to look this up for us based on the client ID of the app?

[lciastko]

I could look it up by the company name that you're working with. Would you feel comfortable with sharing that over the support forums?

Thank you!

[connectorsTray]

Hi,

That would be great! We are working with our customer Aircall who own the app.

Let us know what you find!

[connectorsTray]

Hi Lindsay,

Just following up on the above, were you able to look up the details based on the company name we've provided?

Thanks

[khenle]

Hi,

Thank you for your patience while we investigated this further.

We've determined the Swimlane for Aircall is SL29.

The data center specific REST URLs you can use for this SL are as follows:

oauthUrl https://auth-emea9.bullhornstaffing.com/oauth
restUrl https://rest-emea9.bullhornstaffing.com/rest-services
mobileUrl https://m-emea9.bullhorn.com

I hope this helps!

[connectorsTray]

Thanks Lindsay,

We'll update our settings to use these details and see if this resolves our issues!

[connectorsTray]

Hi Lindsay,

We have implemented the change, unfortunately we are still facing the issue that the refresh token is invalid when attempting to refresh. Could we confirm that the Oauth URL is https://auth-emea9.bullhornstaffing.com/oauth, rather than https://auth-emea.bullhornstaffing.com/oauth as I can see in the documentation here: http://bullhorn.github.io/Data-Center-URLs/?

Thanks