I Built a WordPress Plugin Nobody Asked For

You know that thing where you build something custom for a client, everything runs smoothly for over a year, and then the project simply comes to a natural end?

That's what happened here.

I had a client for over a year. Great working relationship, everything went well. Part of the project was building a custom WordPress plugin that connected their Bricks Builder site with Recruitee - their recruitment platform. The plugin worked perfectly the entire time. Then we stopped working together. Normal agency stuff, nothing dramatic.

So now I have this plugin sitting in a repo, doing nothing. And I figured - maybe someone out there has the exact same problem I solved. Long shot? Probably. But here we are.

The Problem

The client's request seemed straightforward: show their job listings from Recruitee on their WordPress website built with Bricks Builder.

"Just embed the Recruitee widget," you might say. Sure. Except:

• Recruitee's embed is an iframe. Google doesn't index iframe content. No SEO. No organic traffic to your job pages. For a company that wants to attract talent through search, that's a dealbreaker.
• The job pages need to look like the rest of the site. Not like some foreign widget that was slapped on.
• Applications need to go back to Recruitee automatically. The HR team lives in Recruitee. They don't want to check WordPress for applications.

So the real ask was: make the jobs native WordPress content, keep them in sync with Recruitee, and make the application process seamless - all while keeping everything SEO-friendly and indexable.

No big deal, right?

What I Built

The plugin does two things, and it does them well:

Step 1: Pull Jobs from Recruitee

A cron job (configurable - hourly, daily, whatever you need) hits the Recruitee API, pulls all published job listings, and syncs them as a custom job post type in WordPress. Each job gets:

• Title, description, requirements
• Location data (city, state, country)
• Remote status
• Department/position taxonomy
• The Recruitee job ID stored as an ACF custom field

New jobs get created. Updated jobs get updated. Closed jobs get removed. Fully automatic.

The sync also caches departments from Recruitee and maps them to WordPress taxonomies, so you get proper filtering on the frontend for free.

Step 2: Push Applications to Recruitee

This was the tricky part.

I created a Bricks Builder template for the job detail page with a built-in application form. When someone fills out the form - name, email, phone, cover letter, CV upload - the plugin intercepts the Bricks form submission and pushes it to the Recruitee API as a new candidate.

The file upload part was especially fun to figure out. Getting PDFs and documents from a Bricks form upload, making them accessible via URL, and then pushing that URL to Recruitee's attachment endpoint... let's just say the Recruitee API documentation wasn't exactly comprehensive on that front.

But it works. The candidate shows up in Recruitee with their CV attached, linked to the correct job. HR sees it instantly in their pipeline.

The Architecture

For anyone who cares about the code structure:

src/
├── API/RecruiteeAPI.php          # All Recruitee API communication
├── Admin/AdminSettings.php        # WordPress settings page
├── Application/CandidateApplication.php  # Application submission logic
├── Cron/CronManager.php           # Scheduled sync management
├── Integration/BricksFormIntegration.php  # Bricks form hook
├── Logging/ActionLogger.php       # Action logging system
└── Sync/JobSynchronizer.php       # Job sync engine

PSR-4 autoloading via Composer. Clean separation of concerns. The API layer handles retries (up to 3 attempts with backoff). There's a logging system built in so you can see exactly what's happening with syncs and applications in the WordPress admin.

The admin panel lets you configure everything:

• Recruitee API key, company ID, subdomain
• Cron frequency
• Form field mappings (so it works with your specific Bricks form setup)
• Success redirect URL

No hardcoded values. Everything configurable.

The AI Cleanup

Here's the honest part: when I built this for the client, a lot of it was hardcoded. API keys in the code, field IDs baked in, the kind of stuff you do when you're building fast for a specific use case.

When I decided to open source it, I had Claude clean up all the hardcoded values, add proper comments to the functionality, and make everything configurable through the admin settings panel.

Is it perfect? No. Is it production-tested for over a year with a real client? Yes.

Why Open Source It?

Simple: I'm not going to maintain this as a commercial product. We're not working with that client anymore, and I don't have another Recruitee + Bricks project lined up.

But somewhere out there, there's probably a developer or agency pulling their hair out trying to do exactly this. Trying to get Recruitee jobs into Bricks without iframes. Trying to make job applications flow back to Recruitee automatically. Trying to keep everything SEO-friendly.

If that's you - here you go. MIT License. Do whatever you want with it.

How to Use It

1. Drop it in your WordPress plugins directory
2. Run composer install
3. Activate the plugin
4. Go to Bricks Recruitee in the admin menu
5. Enter your Recruitee API key, company ID, and subdomain
6. Import the included ACF fields and Bricks template (JSON files included in the repo)
7. Configure your form field mappings
8. Hit "Sync Jobs Now" or enable the cron

That's it. Your Recruitee jobs are now native WordPress posts with full SEO juice.

The Repo

You can find it on GitHub: Wunderlandmedia/bricks-recruitee

MIT License. Take it, fork it, improve it. If you actually end up using this, I'd love to hear about it. But no pressure - it's a long shot, and I know that.

Sometimes you build things that only help one client. And sometimes, if you're lucky, you build things that help one more.