For web agencies
Every client site independent, and none of them routed through us
If you build and maintain WordPress sites for recruitment agencies, the question that matters is not what the plugin does on one site. It is what happens when you run it on fifteen. Each site connects straight to its own client’s Bullhorn with that client’s own credentials: no shared tenancy, no account of ours in the middle, and nothing that makes one client’s data reachable from another’s site.
One install per site. No central console, by design — see below.
| Started | Trigger | Duration | Result |
|---|---|---|---|
| 09:14:02 | WP-Cron | 6.2s | 34 changes |
| 09:09:01 | WP-Cron | 5.4s | No changes |
| 09:04:00 | WP-CLI | 2.1s | 3 submissions |
| 08:59:02 | WP-Cron | 1.3s | 1 skipped |
What it is
The architecture, because it decides everything else
There is no W3Bullhorn relay. A client’s WordPress site talks directly to that client’s Bullhorn, using a client ID and secret issued to them and saved on their own site by the connection wizard. We are not in the data path, and we do not hold a credential that reaches any client’s records.
For an agency that is the difference between a plugin you can put in front of a client’s security reviewer and one you cannot. Every site stands alone, so the question "could our data end up on another agency’s website" has a structural answer rather than a reassurance: there is no shared store it could travel through.
How it is structured
One site, one install, one connection
The same four steps on every client site you build.
-
Their site
Install on the client’s site
A plugin on their WordPress, in their hosting, under their control. Nothing is hosted by us.
-
Their Bullhorn
Connect their Bullhorn
The client’s own Bullhorn credentials, saved on their site. You never need, and should never hold, a credential shared between clients.
-
WP-CLI
Import, then let it run
A bounded, resumable import from the command line, then an incremental schedule that keeps the board in step.
-
Client
Hand it over
The client manages their own board in their own WordPress admin, which is where they already work.
Repeatable builds
The job pages are yours to build, not ours to impose
The plugin does not take the page over. Your theme keeps its header, footer and design tokens, and every template the plugin ships can be overridden from a child theme by dropping a file in a w3bullhorn/ directory — the active theme is checked first, then its parent, then the plugin. If you build in Elementor instead, there are widgets and dynamic tags for job data, so a designer lays out job pages the same way they lay out everything else.
- Fourteen templates, overridable from the child theme
- Elementor widgets and dynamic tags for job data
- No vendor branding anywhere on the front end
- Your own markup and classes, so your build conventions survive
A privately owned main contractor in Leeds is hiring a senior QS to take commercial ownership of a £40m mixed-use scheme through to practical completion, reporting to the commercial director.
- Five years’ post-graduate experience with a main contractor
- Valuations above £5m run without supervision
Operating a portfolio
Everything operational runs from the command line
The initial import, a resync, a reconciliation dry run, the application delivery queue and a diagnostic bundle are all WP-CLI commands, so they fit the deployment tooling you already use rather than needing somebody to click through an admin screen on fifteen sites. A drift check that tells you Bullhorn’s API has moved exits non-zero, which makes it usable as a scheduled job across a portfolio without parsing output.
- Fifteen WP-CLI commands for import, sync, delivery and diagnostics
- A dry run that reports what a reconciliation would change, and writes nothing
- A drift check that exits non-zero when Bullhorn’s API changes
- Per-site run history and alerts on a failed or stalled sync
| Started | Result |
|---|---|
| 09:14:02 | 34 changes |
| 09:09:01 | No changes |
| 09:04:00 | 3 submissions |
Be clear about this before you quote
There is no cross-site console
-
You manage each site in that site’s own admin
There is no single screen that shows fifteen client boards at once, and we would rather tell you that now than let you discover it after the second build. It follows from the architecture: a console spanning client sites would need a relay holding credentials for all of them, and the deliberate decision was that no such relay exists.
-
Configuration is not synchronised between sites
Field mappings and board settings belong to the site they are on. Two client sites with similar requirements are configured twice, which is the cost of them being genuinely separate.
-
We do not hold your clients’ credentials
Each site holds its own. That means we cannot reach a client’s Bullhorn to help you debug a connection — you or the client will need to run the diagnostics on the site. It is a real trade, and it is the right way round.
W3Bullhorn is an independent product. It is not affiliated with, endorsed by or sponsored by Bullhorn, Inc. Bullhorn is a trademark of its owner.
Specification
What it supports
The detail an agency technical lead asks before standardising on it.
| Installs | One plugin install per site, on the client’s own hosting |
|---|---|
| Bullhorn connection | Per site, using the client’s own Bullhorn-issued client ID and secret |
| Shared infrastructure | None. There is no relay and no account of ours in the data path |
| Theme | Yours. Fourteen overridable templates, plus Elementor widgets and dynamic tags |
| Front-end branding | None added by the plugin |
| Operations | WP-CLI for import, sync, reconciliation, application delivery and diagnostics |
| Cross-site management | Not provided. Each site is administered on its own |
| Licensing and price | Per site. Staging and development installs are not charged — see pricing |
| Extending it | A published, versioned PHP contract surface, hooks, and an admin REST route for add-ons |
FAQ
Questions from web agencies
Short answers here. Anything else, ask us directly.
Keep reading