Recruitee API integration
for careers sites

Two flows usually: vacancy sync from Recruitee to your website (Recruitee is the source of truth, your site reflects what’s published), and apply writeback from your website to Recruitee (candidates fill out the form on your site, application lands in Recruitee with attachments, consent flags, and dedupe checks). Both flows need field mapping (Recruitee vacancy fields to your site’s display logic), validation rules, and error handling so a recruiter typo doesn’t break the careers page.

Optional extensions: bidirectional sync (candidate status updates flow back from Recruitee to your site for logged-in candidates), multi-language vacancy support, role-based access on the admin side, and stats dashboards that pull from Recruitee for board reporting. Job board platform development covers the broader recruitment platform work when the project goes beyond pure integration.

Webhooks where Recruitee supports them, polling where it doesn’t, never both at once for the same data. Webhooks push events to your endpoint when something changes in Recruitee (vacancy published, vacancy paused, vacancy closed, candidate applied, candidate moved to new stage). Near-real-time sync, low load, low cost, but requires your endpoint to be reachable and to handle failures gracefully. Polling means your site asks Recruitee for changes on a schedule (every 15 minutes, every hour, depending on freshness needs). Higher load and slight lag, but simpler and works when webhooks aren’t available or reliable.

Our default: webhooks for the events Recruitee exposes them on, polling fallback for everything else, idempotency keys on both so duplicate events don’t create duplicate records. Cache layer on the read path so the careers page stays fast even when Recruitee is slow. Custom platform work covers the deeper architecture decisions.

Four-layer resilience: retry with exponential backoff for transient failures (network timeouts, 502s, brief outages), queue with persistence for failed events that need to be replayed when service returns, circuit breaker that stops hammering Recruitee when error rates spike to give the API time to recover, and alerts to your team when error rates exceed thresholds you set. For the careers page itself, the cached vacancy list keeps serving while sync recovers in the background, so visitors don’t see an error page.

Rate limits: we respect Recruitee’s published rate limits with token bucket logic, prioritise critical events (new applications) over background sync work, and back off gracefully when we hit the ceiling. Apply submissions get queued and retried with the candidate notified that their application is being processed rather than failing visibly. Backend development work covers the resilience patterns in more depth.

GDPR is part of the integration design, not an afterthought. Candidates see a clear consent statement before submitting (what data goes where, retention period, withdrawal process), with explicit consent flags stored both on your side and passed through to Recruitee. Recruitee itself is GDPR-compliant as an ATS, so the heavy lifting on data controller obligations is shared rather than duplicated. Data minimisation: only fields that actually serve the recruitment process get collected, not “let’s grab everything because we can”.

Retention: Recruitee’s retention policies (typically configurable per company) drive what gets kept and what gets purged. The integration respects those policies rather than creating shadow data on your site that outlives the ATS record. Right-to-be-forgotten requests get handled through Recruitee’s tooling, with the integration automatically reflecting the removal on the careers page. More on how we work covers the broader data handling approach.

Recruitee supports multi-language vacancies natively: each vacancy can have translated versions stored as language variants. The integration reads the correct language version based on your site’s current locale, falls back to the default language when a translation is missing (with a visible note rather than mixed-language content), and routes apply submissions back to the same vacancy regardless of which language the candidate applied in.

Beyond translation: region-specific content (legal text, employer terms, application-flow steps that differ between jurisdictions), language-specific job categorisation, and hreflang implementation for SEO so each language version is properly discoverable. For organisations recruiting across multiple European countries, the integration handles the localisation layer while Recruitee handles the candidate pipeline. CMS development work covers the multi-language structure in more depth.

The integration is built behind a clean abstraction layer, so the ATS-specific logic (Recruitee endpoints, response shapes, authentication) is isolated from your careers page logic (display rules, apply forms, candidate flow). Switching ATS means rewriting the integration layer, not rebuilding your careers page or your visible application experience. Typical timeline for an ATS switch (Recruitee to Bullhorn, Teamtailor, OTYS, Workable, etc.) is two to four weeks for the technical work, plus your team’s data migration timeline on the ATS side.

What complicates ATS switches: differences in how each ATS models vacancies (some have richer stage workflows, some have different candidate profile structures), different webhook reliability and API maturity, and any custom fields you’ve built into Recruitee that need mapping equivalents on the new ATS. We’ve handled migrations across most common ATSs (Recruitee, Bullhorn, Teamtailor, OTYS, Cockpit, Workable, Personio). Discovery call covers your specific situation.

Cost drivers: scope of integration (vacancy sync only versus vacancy sync plus apply writeback plus status updates), starting state (clean WordPress site versus existing site with legacy custom code that needs untangling), volume of custom fields and mapping complexity, multi-language and multi-region requirements, and how much resilience tooling is needed (basic retries versus full queue with circuit breaker plus monitoring dashboard plus alerts).

Typical project ranges: focused vacancy sync with apply writeback on an existing well-built WordPress site runs €6,000 to €15,000. Fuller integration with custom field mapping, multi-language support, monitoring tooling, and runbook documentation runs €15,000 to €35,000. Custom integration work on custom-built sites (not WordPress) varies more depending on what we’re integrating into. Our hourly rate is €60 to €65 across roles. Typical timeline: 3 to 6 weeks for focused builds, 6 to 12 weeks for fuller integrations. Pricing and rates page covers the broader rate structure.