What Kini does for employers on Eploy.
Eploy is built to follow each employer's own recruitment workflow. Kini reads the vacancies and writes candidates and applications into that workflow for every end customer you connect.
Vacancies with job description, location and address
Eploy's vacancy interface covers job descriptions, locations and addresses. Kini searches the employer's Eploy system for the vacancies that should be advertised, using Eploy's filters on vacancy fields, and imports each one with the details candidates need before they decide to apply.
Applications placed in the right workflow stage
Eploy lets an integration set an application's workflow stage, and the status within that stage, at the moment the application is created. Kini uses the stage the end customer chooses for new applicants, so recruiters find them exactly where their own process begins.
Questions, answers and the source of each application
Eploy's application interface covers questions and answers as well as the source of each application. Kini delivers the candidate's answers with the application and records your channel as its source, so the recruiting team sees where applicants come from and what they answered.
Access tied to a user and its permissions
Every Eploy API key is linked to a user record and reaches only what that user and the key's own API permissions allow, and only from approved IP addresses. The end customer therefore decides precisely which parts of Eploy the connection can read and write.
Every vacancy, page by page
Eploy returns search results in pages and states the total number of records and pages in every response. Kini works through all pages of a vacancy search, so employers with many open vacancies get every one of them into your channels, not only the first batch.
Every field. Every entity.Exactly where it belongs.
Kini works with three areas of Eploy's API: vacancies come in, candidates and applications go back. Where the public developer guide names a field, it is spelled the same way below; elsewhere the list gives the documented categories.
Vacancies
Candidates
Applications
Each Eploy customer runs its own system, and an Eploy API key only answers requests from the IP addresses assigned to its user. The end customer therefore registers the addresses Kini connects from when it creates the key for Kini.
Operations like GET, POST, PATCH are documented per endpoint in the . The primary source for field definitions. Kini adds mapping and fallback logic on top.
End-to-end GDPR consent
Every application that flows through Kini carries a consent flag, mirrored on the target system's side and traceable in audits.
Native-language custom fields
Locations, departments and sources are mapped correctly even when they use German naming conventions or regional variants, whether your customers sit in DACH or operate internationally.
Application flows for a wide range of job boards
Stepstone, Indeed, Jobrapido and regional boards each have their own required fields, screening patterns and encoding rules. Kini's mapping engine is trained for those: out of the box, not as a custom project.
Operated by the Kini team
Kini runs the connection for you, including monitoring and alerts. If a vendor changes an API or a mapping breaks, our team fixes it before it reaches your funnel. Operated from Germany.
Frequently asked questions about the Eploy integration.
Which Eploy vacancies Kini publishes, where new applications appear in the employer's workflow, and how the employer sets up API access in Eploy.
Vacancies come in from Eploy with their descriptions, locations and addresses. Kini creates candidates and their applications in Eploy, with answers to the vacancy's questions and your channel as the source. Kini does not change vacancies and does not touch placements, payroll or other back-office data.
With an API key created in the employer's Eploy system. The key is assigned to a user whose permissions it inherits, it can be limited to specific API endpoints, and it only works from the IP addresses assigned to that user. Eploy then issues the client credentials Kini uses to sign in.
Yes. Since version 44, Eploy accepts a workflow stage, and where that stage has statuses also a status, when an application is created. The employer can therefore have applicants from your channels start in a screening stage instead of the default first step.
Eploy checks permissions on two layers: the user behind the API key needs access to the area concerned, and the key itself can be restricted to a subset of endpoints. If either layer is missing a permission, Eploy denies the request until the employer's administrator adjusts it.
No. Eploy remains the employer's system of record for vacancies, candidates, workflows and placements. Kini publishes the vacancies to the channels where candidates find them and creates the resulting applications in Eploy, where the recruiting team follows its own process.
Kini keeps personal application data for 180 days after an application was created and anonymises it then, removing contact details, attachments, notes and screening answers. Processing happens in Frankfurt within the EU under a data processing agreement; Eploy keeps its records under the employer's policy.
Trusted by recruiting teamsacross europe.
From enterprise HR platforms to lean recruiting boutiques. Teams use Kini to connect their tools without involving engineering. Here's what they say.
"Kini syncs candidates from Perspective straight into our customers' ATS. That saves us manual transfers and around four hours a week."
"Kini gets enterprise customers on SAP SuccessFactors live much faster. Fewer technical hurdles in sales, around 20% more conversion."
"With Kini, we sync candidates straight into our customers' ATS through 65+ integrations. We don't need an extra full-time hire for it."
