KeRecruitment to HR
Recruitee to Keka integration: hired candidates as employees in Keka HR
With an integration between Recruitee and Keka, a candidate hired in Recruitee automatically becomes an employee in Keka, with employee number, name, email, mobile number, date of joining, department, business unit, location, legal entity and job title. KoppelHet stores what Keka returns with the candidate, so a second notice does not create a duplicate employee.
What the integration does
Organisations with Keka as HR system that recruit their European roles in Recruitee have two separate worlds. Every hire is then entered into Keka by hand, and assigning the right legal entity and location regularly goes wrong.
- The recruiter marks the candidate as hired in Recruitee and fills the profile fields for work email, start date and entity.
- KoppelHet translates job and placement location into the names of department, business unit, location and entity as they appear in Keka.
- KoppelHet creates the employee in Keka.
- Keka's response is stored in the KoppelHet platform, linked to the candidate from Recruitee.
- HR completes in Keka the parts the API does not create, such as salary and leave policy.
What to watch for with Recruitee and Keka
- Keka accepts only a fixed list of fields for a new employee and rejects any other field. Custom fields or profile questions from Recruitee therefore do not come along on creation, but stay in Recruitee or become a task for HR.
- Department, business unit, location and legal entity are text fields in the Keka API. KoppelHet translates the job and placement location from Recruitee into exactly the names that exist in Keka, so no variant with a different spelling is created.
- Gender is a number from 0 to 3 in Keka, and the documentation does not say which number means what. KoppelHet therefore leaves the field empty until the values are confirmed in the test environment.
- The date of joining is a date-time in Keka. KoppelHet converts the start date from Recruitee with a fixed time zone, so a Dutch start date does not shift by a day.
- The Keka API allows fifty requests per minute. At a peak in hires, for example a group of starters, KoppelHet spreads the calls instead of running into an error.
- Keka provides a separate demo environment on kekademo.com. KoppelHet tests the creation there, before the integration runs on the company's live Keka environment.
How we build and run it
- The integration runs on the KoppelHet platform, hosted in a data centre in the EU.
- Every sync and every error is visible in the functional log; on an error your administrator is notified.
- A change that cannot go through is not half-applied but queued for another attempt.
- KoppelHet is ISO 27001 certified. Data travels encrypted and stays on the platform no longer than needed.
- After go-live we manage the integration and adjust it when your process changes.
- The integration fits next to your existing integration layer. Only the fields in the design are transferred; the platform keeps no register of its own.
Implementation and price
This is not an app you switch on. We build the integration for your organisation on our platform, with building blocks we reuse on every project. So it is custom work that does not start from scratch.
A consultant prepares the intake and analyses both systems. We then record the mapping and exceptions field by field, test in the test or acceptance environment and go live at a moment you choose. Costs are a one-off amount for the setup and a monthly amount for platform, monitoring and support.
Frequently asked questions
Why not Keka's recruitment module?
It exists, but teams recruiting in Europe have often chosen Recruitee. The integration lets both coexist.
Does the salary from the offer come along?
Not through this call. The public API only creates the employee, so HR sets up the salary structure in Keka.
Does this work for several entities?
Yes. Per job we record which legal entity and business unit the hire belongs to.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Recruitee is read through the signed candidate_moved webhook (hire stage category, X-Recruitee-Signature header) and the ATS API for offer, placement location and profile fields.
- To Keka through POST https://{company}.keka.com/api/v1/hris/employees with an access token from login.keka.com (scope kekaapi, client_id, client_secret and api_key). Fields employeeNumber, displayName, firstName, middleName, lastName, email, mobileNumber, gender, dateOfBirth, dateJoined, department, businessUnit, jobTitle, secondaryJobTitle, location, legalEntity and nationality; additionalProperties is off. Response with succeeded, message and data.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Recruitee | Field in Keka | Notes |
|---|---|---|
name | firstName, middleName en lastName | Name prefix separate |
Zakelijk e-mailadres (profielveld) | email | |
phones[0] | mobileNumber | |
Startdatum (profielveld) | dateJoined | Date-time; time zone fixed |
offer.department | department | Name as in Keka |
placement_locations[0] | location | |
Vacature (vertaaltabel) | businessUnit en legalEntity | |
Vacaturetitel | jobTitle | |
Personeelsnummer volgens reeks van HR | employeeNumber |
Related
Recruitee → ADP Workforce Now
Recruitee to ADP Workforce Now integration: hired candidates as an in-progress hire
Recruitee → AFAS Profit
Recruitee to AFAS integration: from hired candidate to new employee
Recruitee → AlexisHR
Recruitee to AlexisHR integration: hired candidates as employees in Simployer One
Recruitee → BambooHR
Recruitee to BambooHR integration: hired candidates in BambooHR without clicking and retyping