Seen on top review platforms
A basic connector moves data once, then quietly gives up when reality arrives. You need clear ownership, strict mapping rules, and failure handling. Otherwise your team becomes the integration, again.

Some facts
environments keep you sane: sandbox, staging, production.
things should be logged per sync: record ID, action, payload, response, timestamp.
decision prevents conflicts: which system is allowed to edit each field.
If Cockpit needs to play nicely with a WordPress careers site, a custom portal, or other stacks like Bullhorn, Recruitee, Teamtailor, or OTYS, we’ll design the sync around constraints, not guesses.
We’ve been building and maintaining digital products long enough to know what breaks, what scales, and what “urgent” actually means.
Studio Ubique works with startups, agencies, and mid-sized companies who want their product to work better than their competitors’ excuses. Since 2012, with clients across 15+ countries.
The questions that come up most often, answered here. Yours not among them? Just ask, there's a human on the other end.
Cockpit integration projects typically sit between €10.000 and €25.000 for the build, slightly lower than equivalent Bullhorn projects because Cockpit’s API is more consistent and custom field structures are usually cleaner in Dutch staffing instances. A simple read-only feed (jobs from Cockpit to a WordPress careers site) starts around €8.000. Bidirectional sync with field mapping, application write-back, and basic monitoring lives between €12.000 and €20.000. Complex multi-brand setups with multi-language career sites, multi-entity sync (jobs plus candidates plus placements), and custom field mappings run €20.000 to €30.000+. Hourly rates run €60 to €65 across all roles. A first call with your Cockpit instance details and an example careers site URL gives a realistic range within a week.
Standard entities: vacatures (jobs), kandidaten (candidates), aanmeldingen (applications), plaatsingen (placements), opdrachtgevers (clients/companies), and gerelateerde activiteiten (linked activities). For uitzendbureaus and detacheerders, the placement and client entities matter as much as jobs and candidates. A staffing-focused site might need: jobs flowing from Cockpit to the site, applications flowing back to Cockpit as kandidaten with the right source attribution, plus client portals where opdrachtgevers can view active placements and submit new vacancies that flow back into Cockpit. Custom fields per Cockpit instance get handled in the mapping document during scoping. The FlevoDirect case shows a similar Dutch staffing ATS setup with multi-entity sync in production.
All three work. WordPress is the most common for Dutch staffing agencies because the editorial flexibility matters for employer branding, sector-specific landing pages (zorg, techniek, onderwijs, etc.), and content marketing for candidate acquisition. Headless setups (WordPress + Next.js, or Strapi + Next.js) make sense when the site needs higher performance, advanced filtering on job lists, or shared content across multiple brand sites under one CMS. Custom CMS or portal-style builds happen when the site is part of a larger product (a candidate portal with login, a client portal with reporting). The Cockpit integration layer itself runs the same regardless: a Node or PHP service that handles API calls, caching, and write-back logic. Custom recruitment websites remain the broader service with Cockpit integration as one technical component.
Both, picked per entity based on what Cockpit supports and what the entity needs. Cockpit has reasonable webhook support compared to older ATS platforms: real-time updates for job status changes, candidate updates, and application submissions usually work via webhooks. For entities where webhooks aren’t reliable or supported, scheduled polling at intervals appropriate to the entity: jobs every 5-15 minutes, candidate updates every few minutes during active recruiting, placements and clients on longer schedules since they change less frequently. Caching sits between the site and Cockpit so filters and category browsing don’t hammer the API on every visitor click. The honest answer to “real-time?” is “near real-time” — typically a 30-second to 5-minute delay on most entities, which recruiters and candidates don’t notice in practice.
Yes, and it’s common for Dutch staffing groups operating multiple brand identities (a healthcare brand, a tech brand, a hospitality brand) from one Cockpit backend. The integration layer reads jobs from Cockpit and routes them to the correct brand site based on Cockpit field values (afdeling, brand tag, sector, location). Multi-language sites (NL, DE, EN, sometimes FR or PL for international staffing) work either through translated content fields stored in Cockpit, or through a translation layer that connects Cockpit’s Dutch source content to translated versions managed in the CMS. For multi-brand groups, the same integration layer can serve four or five branded career sites without duplicating the Cockpit instance or the integration work, which is usually the biggest economic advantage of going custom over packaged solutions.
A simple Cockpit-to-site read-only feed takes two to three weeks from kickoff to live. Standard integration with field mapping, application write-back, and basic monitoring runs four to seven weeks. Complex multi-brand or multi-entity setups (multiple career sites, plus client portals, plus candidate portals, all reading from one Cockpit instance) run two to four months. The main variable is rarely our side. Cockpit API credentials and the specific permissions needed for each entity type can take days or weeks to arrange depending on your Cockpit administrator and account tier. The faster credentials and sample data arrive, the faster everything else moves. Our broader ATS integration page covers the general approach for context, including how the same pattern applies to Bullhorn, Recruitee, Teamtailor, and OTYS.
Book a quick 30 min video call, we will show you exactly what to fix. We reply within 24 hours.