How Kini works with Factorial's ATS.
Factorial keeps job postings, candidates and applications as separate records. Kini reads the postings and writes candidates and applications for each end customer you connect. The cards below show what that involves.
Published postings, complete with their address
Kini imports the postings an end customer has published in Factorial and leaves drafts, unlisted and archived postings out. Factorial keeps the address in a separate location record, so Kini reads that record for every posting and adds street, postcode, city, country and coordinates. Contract type, schedule, workplace type and category come along with each job.
One candidate per person, found by email
Before Kini creates a candidate, it searches the end customer's Factorial candidates for the applicant's email address. When the person already exists, for example from an earlier application, the new application is added to that record. Only without a match does Kini create a candidate, with name, email, phone, LinkedIn profile and gender in Factorial's own values.
Applications on the right posting, with the CV attached
Kini creates each application in Factorial on the job posting the candidate applied for and links it to the candidate record, together with the phone number. The CV is then uploaded to that application. If none of the files is marked as a CV, Kini takes the first document the candidate attached instead.
The channel as source, in your customer's terms
Every candidate and application reaches Factorial with the channel it came from recorded as its source. Where an end customer already uses its own source names in Factorial, Kini translates channel names into those values. Kini can also set a medium per end customer, the field Factorial provides for extra detail about a source.
A clear outcome for every application
Kini records how each delivery to Factorial ended. An application for a posting that Factorial no longer finds is marked as an expected failure rather than an error, and rate limits or temporary server errors lead to an automatic retry. Partners follow each outcome through Kini's API or the sync status webhook instead of asking whether an application arrived.
Every field. Every entity.Exactly where it belongs.
Kini exchanges four kinds of records with Factorial's ATS: job postings and their locations come in, candidates and applications go back. Each field below carries the name it has in Factorial's API reference.
Job Postings
Locations
Candidates
Applications
Candidates and applications are separate records in Factorial, and one candidate can hold applications to several job postings. That is why Kini looks a candidate up by email before it writes an application, rather than creating a new person each time.
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 Factorial integration.
What Kini reads from Factorial, how applications are written into it, and what an end customer's account needs before the connection runs.
Job postings come in from Factorial, each with the location record that holds its address. In the other direction, Kini writes candidates and applications into Factorial's ATS, with the CV uploaded to the application and the channel recorded as source. Kini does not change job postings in Factorial; it only reads them.
Those with the status published. Factorial also knows draft, unlisted, archived and cancelled postings, and Kini leaves all of these out, so a posting reaches your channels only once the end customer has published it. When a posting stops being published, the next import no longer finds it and Kini archives the job.
Once an hour by default. The import interval is configured per end customer, so an account that changes rarely can be read on a slower rhythm. Applications do not wait for that interval: Kini queues each one for delivery to Factorial as soon as it arrives, independently of the job import.
Kini reuses the existing record. It searches Factorial for the applicant's email address first, and when it finds a candidate, the new application is attached to that person instead of a second candidate being created. Contact details already stored on the existing candidate are left as they are.
Yes, as text. Kini writes the candidate's answers into the application's cover letter field, each as the question followed by the answer, together with any note the candidate left. Factorial's API also offers a field for structured answers, which Kini does not use at present, so answers do not appear as separate entries.
If the job posting no longer exists, or Factorial reports that the candidate is already registered, Kini marks the application as an expected failure, which needs no action. After a rate limit or a temporary server error, Kini tries the delivery again on its own. Any other rejection is marked as failed, and every status is visible through Kini's API.
An API key for the account. According to Factorial's documentation, only an admin can create one, a key gives access to all of the company's data rather than a limited scope, and it stays valid until it is revoked. Kini uses the key to read job postings and to write candidates and applications.
No. Factorial remains the system of record for jobs, candidates and applications. Kini connects it to the channels where your end customers' jobs appear and brings the resulting applications back. Recruiters keep working in Factorial, while Kini runs the connection in between as a managed service.
Personal data in an application, such as contact details, attachments and answers, is anonymised in Kini 180 days after the application was created. Kini hosts its data in the EU, in Frankfurt, and offers a data processing agreement. The candidates and applications written into Factorial stay there under the end customer's control.
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."
