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
-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!
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.
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,
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!
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
Code: Select all
I hope that this helps!
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.
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.
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:
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?
That would be great! We are working with our customer Aircall who own the app.
Let us know what you find!
Just following up on the above, were you able to look up the details based on the company name we've provided?
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:
I hope this helps!
We'll update our settings to use these details and see if this resolves our issues!