Was Kini mit dem Recruiting-Modul von Kenjo macht.
Kenjo deckt weit mehr ab als Recruiting, für diese Verbindung zählt aber nur das Recruiting-Modul. Kini liest dort Positionen und schreibt Kandidat:innen und Bewerbungen für alle angebundenen Endkund:innen, wie die fünf Karten unten zeigen.
Aktive Positionen, komplett mit Adresse
Kenjo gibt jeder Position einen von vier Status: Active, Draft, Closed oder Archived. Kini veröffentlicht nur aktive Positionen, mit Stellentitel, HTML-Beschreibung und Positionsart, und ergänzt Straße, Postleitzahl, Ort und Land aus dem Büro, zu dem die Position gehört, sodass jeder Job mit vollständiger Adresse ankommt.
Kandidat:in und Bewerbung, jeweils an ihrem Platz
Kenjo speichert Person und Bewerbung als getrennte Datensätze. Für jede bewerbende Person legt Kini eine Kandidat:in mit Vorname, Nachname, E-Mail und Telefon an und dann eine Bewerbung, die sie mit der gewählten Position verknüpft. Recruiter:innen sehen die Person sofort in der Pipeline der Position.
Der Kanal an beiden Datensätzen
Kenjo hat ein Quellenfeld an der Kandidat:in und eine eigene Quelle an jeder Bewerbung. Kini füllt beide mit dem Kanal, über den sich die Person beworben hat, sodass Endkund:innen in Kenjo sehen, woher Kandidat:innen kommen, egal ob sie auf Personen oder auf einzelne Bewerbungen schauen.
Lebensläufe bei der Kandidat:in
Der Lebenslauf und alle weiteren Dokumente aus der Bewerbung werden als Anhänge zur Kenjo-Kandidat:in hochgeladen. Recruiter:innen öffnen sie dort, wo sie die Person ohnehin prüfen, statt ein Postfach zu durchsuchen. Kenjo nimmt Dateien auch an der Bewerbung selbst an, für Dokumente, die zu einer bestimmten Position gehören.
Die eigenen benutzerdefinierten Felder der Endkund:innen
Kenjo erlaubt jedem Unternehmen eigene benutzerdefinierte Felder an Kandidat:innen und Bewerbungen, erkennbar am Präfix c_. Kini überträgt Antworten aus deinem Bewerbungsformular in diese Felder, sodass Angaben, auf die sich das Recruiting-Team verlässt, etwa Verfügbarkeit oder Gehaltsvorstellung, in den Feldern ankommen, nach denen es filtert.
Jedes Feld. Jede Entität.Genau dort, wo es hingehört.
Kini arbeitet mit vier Kenjo-Datensätzen: Positionen und die Büros, zu denen sie gehören, kommen herein, Kandidat:innen und Bewerbungen gehen zurück. Die Schlüsselfelder sind genau so geschrieben wie in Kenjos API-Referenz.
Positionen
Büros
Kandidat:innen
Bewerbungen
Kenjo speichert die Adresse einer Position am zugehörigen Büro, nicht an der Position selbst. Kini liest für jede Position das Büro, sodass der Job mit Straße, Postleitzahl, Ort und Land in deinen Kanälen erscheint.
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.
Schritt 1Verbinden
Schritt 2Mappen
Schritt 3Testen
Schritt 4Go-live!
mit deinem Stack funktioniert?
Häufige Fragen zur Kenjo Integration.
Welche Kenjo-Positionen Kini veröffentlicht, wie Bewerbende in Kenjo geschrieben werden und was Endkund:innen mit Kenjo klären, bevor die Verbindung startet.
Positionen kommen aus dem Recruiting-Modul von Kenjo, jeweils mit dem Büro, das ihre Adresse enthält. Kini schreibt Kandidat:innen, ihre Bewerbungen und die hochgeladenen Dokumente zurück in Kenjo. Positionen und Büros liest Kini nur und ändert sie nicht, und Mitarbeiter-, Zeiterfassungs- und andere HR-Daten von Kenjo bleiben unberührt.
Die mit dem Status Active. Positionen im Status Draft bleiben draußen, bis Endkund:innen sie aktivieren, und eine Position, die auf Closed oder Archived gesetzt wird, verschwindet beim nächsten Import: Kini archiviert dann den Job und meldet die Änderung über seine Job-Updates.
API-Zugang zum eigenen Kenjo-Konto. Laut Kenjos Dokumentation muss die API zuerst vom Customer-Success-Team von Kenjo aktiviert werden. Danach erzeugt ein Admin in den Kenjo-Einstellungen einen API-Key und trägt ihn in Kinis Setup-Formular ein, die einzige Zugangsangabe, die die Verbindung braucht.
Ja. Kenjo nimmt benutzerdefinierte Felder mit dem Präfix c_ an, wenn eine Bewerbung angelegt oder eine Kandidat:in aktualisiert wird. Kini ordnet die Antworten deines Bewerbungsformulars den Feldern zu, die Endkund:innen benennen, sodass Angaben, nach denen das Recruiting-Team filtert, als strukturierte Daten in Kenjo ankommen.
Nein. Kenjo bleibt das System of Record der Endkund:innen für Positionen, Kandidat:innen und Einstellungen sowie für den Rest ihrer HR-Arbeit. Kini ergänzt die betriebene Verbindung zu den Kanälen, in denen diese Positionen ausgeschrieben werden, und stellt die daraus entstehenden Bewerbungen zu.
Kini behält die Bewerbung und meldet den Grund. Jede Bewerbung hat in Kini einen Sync-Status, und deine Plattform erhält Änderungen per Webhook oder per Abfrage. Ein erwartbarer Fall, etwa eine nicht mehr veröffentlichte Position, wird als erwarteter Fehlschlag markiert; alles andere trägt seine Fehlermeldung, damit jemand reagieren kann.
Höchstens 180 Tage in personenbezogener Form. Danach anonymisiert Kini die Bewerbung und entfernt Kontaktdaten, Dokumente, Notizen und Screening-Antworten. Kini verarbeitet die Daten in Frankfurt in der EU und bietet einen Auftragsverarbeitungsvertrag an; die in Kenjo geschriebenen Datensätze folgen den eigenen Regeln der Endkund:innen.
Recruiting-Teams in ganz Europavertrauen auf Kini.
Von Enterprise-HR-Plattformen bis zu schlanken Recruiting-Boutiquen. Teams verbinden mit Kini ihre Tools, ohne Engineering einzubinden. Das sagen sie.
„Kini synchronisiert Kandidaten aus Perspective direkt in die ATS unserer Kunden. Das spart uns manuelle Übertragungen und rund vier Stunden pro Woche.“
„Mit Kini gehen Enterprise-Kunden auf SAP SuccessFactors deutlich schneller live. Weniger technische Hürden im Vertrieb, rund 20 % mehr Conversion.“
„Mit Kini synchronisieren wir Kandidaten direkt mit den ATS unserer Kunden, über mehr als 65 Anbindungen. Dafür brauchen wir keine zusätzliche Vollzeitstelle.“
