Users have been reporting an increase in 429 errors while running existing/new scripts in the APIs. This post is to give some insight into the hows and whys of 429 errors, what we at Bullhorn are doing to help alleviate the impact, and what you can do on your end with your code.
There is built-in error handling specifically for 429s in our publicly-available open-source SDK as an indicator for baseline recommendations. The default HTTP-429 handling in the Bullhorn REST SDK is:
Wait 1 second and try again (Thread.sleep(1000);)
Attempts 3 times (API_RETRY variable)
Handled in this file, roughly lines 2071-2091 (few other subroutines are elsewhere in the file)
This can certainly be built out with more nuance in that, for example; Execute more tries with a shorter wait between, and then if still receiving fails, essentially suspend the transaction & logs on a database table for reinitiation in the next .5-1 hour span.
The root package for the SDK may be found here: https://github.com/bullhorn/sdk-rest
Here are a few frequently asked questions relating to infrastructure & cluster concerns for QoS limiting:
- Auto retry every second until successful adds additional load on our end , Retry is fine if this occurs rarely but in this case it’s happening almost every day, we had one today as well
- We were not aware of the new response code , is it possible to subscribe for any future changes in API
- This week we saw capacity exceeded errors almost every day , our volumes are very low and are concerned when we move other LOBs
- What action is taken by Bullhorn internally for Server API capacity exceeded responses to avoid/minimize 429 response codes?
- Does Bullhorn auto scale and how often capacity planning is done on API servers?