Troubleshooting
Hitting Bullhorn rate limits
Bullhorn limits how much any integration may ask of it. When that limit is reached the API starts refusing requests, and the run history records it rather than hiding it. The usual cause is not this plugin by itself.
Diagnose
How to tell
The run history on W3Bullhorn → Sync records rate-limit responses per run alongside the API call count and duration. If a run shows them, the connection was being throttled while it worked.
Refusals are handled and counted rather than retried blindly. A run that meets a limit does not hammer the API harder until Bullhorn gives in, which is what turns a throttle into a suspension.
Causes
What usually causes it
This plugin is rarely the whole story.
- Another integration on the same credentials. The limit applies to your Bullhorn account, not to one plugin. A second integration, a BI tool or somebody’s script shares the same budget. This is the commonest cause by a distance.
- A backfill running at the same time as normal work. An initial import of a large catalogue is the heaviest thing the plugin ever does. Run it when nothing else needs the API.
- A schedule far tighter than the catalogue needs. Syncing every few minutes on a board that changes twice a day spends your API budget for no benefit.
- A genuine fault elsewhere. Repeated failed runs that each retry will consume the budget. Fix the underlying failure rather than the symptom.
Usage
What this plugin costs, so you can rule it out
Measured figures, useful when your Bullhorn administrator asks.
Because the sync pages forward from the point it last reached rather than re-reading the catalogue, its usage is modest and does not scale with the board: a cycle with nothing to do costs one API call, a walk over a hundred roles costs one, and a walk over a thousand costs three. Ten times the catalogue does not cost ten times the calls.
If your account is hitting limits and this plugin is syncing hourly over a normal board, the arithmetic says the cause is somewhere else. That is a useful thing to be able to demonstrate.
Check the drift check too
Bullhorn occasionally changes its API. <code>wp w3rp bullhorn drift-check</code> reports whether anything has moved under you, and exits non-zero on a breaking verdict, so it works as a scheduled monitor. A change at the Bullhorn end can look like a rate problem from the outside.