Echte Fragen von Teams,
‍die ihr Recruiting vernetzen.

Managed Recruiting Connectivity heißt: Ein Anbieter baut, betreibt und überwacht die Integrationen zwischen deinen Recruiting-Systemen, nicht nur die erste Verbindung. Das ATS bleibt das System of Record. Der Connectivity-Layer bringt Stellen nach außen und Bewerbungen zurück und kümmert sich dauerhaft um Wiederholungsversuche, Mapping-Änderungen und Connector-Updates.

Entscheidend ist, wer langfristig verantwortlich ist. Zwei Systeme zu verbinden, ist ein einmaliges Projekt. Diese Verbindung durch API-Änderungen, neue Pflichtfelder und geänderte Plattformregeln am Laufen zu halten, ist eine Betriebsaufgabe. Managed Connectivity schreibt diesen zweiten Teil in den Vertrag statt auf deine Roadmap.

Eine ATS-Integration verbindet ein Bewerbermanagementsystem mit einem anderen Tool, etwa einer Jobbörse oder einem Social-Recruiting-Kanal, sodass beide Stellen und Kandidatendaten automatisch austauschen. Ohne sie übertragen Recruiter Stellenanzeigen und Bewerbungen von Hand.

In der Praxis entscheiden drei Dinge, ob eine Integration hält: das Feld-Mapping zwischen Systemen, die Kandidaten unterschiedlich abbilden, die Fehlerbehandlung, wenn eine Seite nicht erreichbar ist, und wer den Connector pflegt, wenn ein Anbieter seine API ändert. Die meisten Integrationen scheitern am dritten Punkt, nicht am ersten.

Eine Unified API bündelt viele Systeme hinter einem generischen Schema, aber bauen, überwachen und reparieren musst du die Integration weiterhin selbst. Managed Connectivity pflegt recruitingspezifische Mappings pro System und übernimmt den Betrieb: Monitoring, Wiederholungsversuche, Wiederherstellung und Connector-Updates, wenn ein Anbieter seine API ändert.

Es ist eine Abwägung zwischen Abstraktion und Genauigkeit. Ein generisches Schema ist schnell eingeführt, ebnet aber die Details ein, auf die es im Recruiting ankommt: Phasen im Bewerbungsprozess, Screening-Fragen, Veröffentlichungsregeln einzelner Jobbörsen. Mappings pro System erhalten diese Details und verlagern den Pflegeaufwand zum Anbieter.

Allgemeine iPaaS-Tools verschieben Ereignisse zwischen Apps, verstehen aber nichts von Recruiting. Sie wissen nicht, was eine Bewerbungsphase, eine Screening-Frage oder ein doppelter Kandidat ist, und überlassen dir Mapping, Wiederholungsversuche und die Regeln der einzelnen Jobbörsen. Recruiting-spezifische Connectivity bringt diese Standards pro System geprüft mit.

Die Lücke zeigt sich in den Sonderfällen, nicht im Normalfall. Ein generischer Workflow kann eine Stelle veröffentlichen. Er kann dir aber nicht sagen, dass eine Jobbörse sie wegen einer fehlenden Gehaltsangabe abgelehnt hat, dass ein Kandidat im Ziel-ATS schon existiert oder dass eine Screening-Antwort nicht mehr zur zugehörigen Frage passt.

Multiposting heißt, eine Stellenanzeige auf vielen Jobbörsen gleichzeitig zu veröffentlichen, statt sie auf jeder Plattform einzeln einzugeben. In der Praxis braucht das ein Feld-Mapping pro Jobbörse, weil jede andere Daten erwartet. Deshalb läuft Multiposting meist über einen Integrations-Layer und nicht über ein Formular.

Komplex ist nicht das Veröffentlichen selbst, sondern alles drumherum: Jede Jobbörse hat eigene Pflichtfelder, Zeichenlimits, Kategorien und Veröffentlichungsregeln, und jede liefert Bewerbungen in einem eigenen Format zurück. Diese Unterschiede müssen irgendwo aufgelöst werden, entweder von deinem Team oder vom Connector.

Ja. Für jedes ATS, das Kini bereits unterstützt, gibt es den Connector und sein Standard-Mapping, und alles Kundenspezifische mappt das Kini-Team. Eine Person braucht es nur für den Zugang: Jemand im Unternehmen muss die Verbindung zum eigenen ATS freigeben, meist über einen Magic Link.

Nützlich wird ein Entwickler in der anderen Richtung: wenn du Stellen übertragen oder Bewerbungsdaten in dein eigenes Produkt holen willst. Das läuft über die öffentliche API, ist aber optional, weil der Managed-Weg komplett über die App funktioniert.

Einen Connector zu bauen, ist ein Projekt. Zwanzig am Laufen zu halten, ist ein Team. Die laufenden Kosten stecken in der Pflege: API-Änderungen, Sonderfälle, Monitoring und die Verwaltung der Zugangsdaten jedes Kunden. Selbst bauen lohnt sich, wenn Integrationen dein Produkt sind. Einkaufen lohnt sich, wenn sie die Voraussetzung dafür sind, dein Produkt zu verkaufen.

Ein hilfreicher Test: Zähl, wie viele deiner Kunden innerhalb einer Stunde merken würden, dass ein Connector keine Bewerbungen mehr liefert. Lautet die Antwort „die meisten“, betreibst du eine Betriebsfunktion und kein Projekt. Die braucht Personal, Rufbereitschaft und Monitoring, egal wer den Code geschrieben hat.

Sie lösen ein anderes Problem gut: breite HR-Abdeckung hinter einem Schema, gedacht für Produktteams, die die Integration selbst bauen und betreiben. Kini ist auf Recruiting spezialisiert und übernimmt den Betrieb: Onboarding pro Kunde, Monitoring, Wiederholungsversuche und Connector-Pflege. Was passt, hängt davon ab, ob du eine API oder einen Betreiber suchst.

Dazu kommt ein Unterschied in der Abdeckung. Unified APIs konzentrieren sich auf HR- und Payroll-Systeme. Recruiting-Workflows brauchen zusätzlich Jobbörsen, Social-Recruiting-Kanäle und Screening-Tools samt den passenden Veröffentlichungsregeln. Endet dein Anwendungsfall beim ATS, reicht eine Unified API womöglich aus.

Das Onboarding beginnt mit einem Gespräch über deinen Anwendungsfall, die Volumen und die Systeme deiner Kunden. Danach führen wir das erste Magic-Link-Onboarding mit einem Pilot-Endkunden durch, prüfen es mit einer echten Testbewerbung und gehen gemeinsam live. Der AVV wird vor dem Go-live unterschrieben.

Der Pilot soll die Besonderheiten deines Setups sichtbar machen, bevor sie sich vervielfachen: welche Systeme deine Kunden tatsächlich nutzen, welche Felder dir wichtig sind und wie Bewerbungen bei dir ankommen sollen. Was wir dabei lernen, wird zum Standard für alle Kunden, die du danach anbindest.

Für ein ATS, das Kini bereits unterstützt, ist die Verbindung selbst in Minuten eingerichtet, sobald wir die Zugangsdaten haben. Länger dauert meist, sie zu bekommen: Manche ATS-Anbieter müssen zuerst selbst etwas tun, etwa einen API-Key oder ein Zertifikat ausstellen oder Kini auf eine Allowlist setzen. Danach prüft Kini das Setup mit einer Testbewerbung und aktiviert die Integration.

Nutzt dein erster Kunde ein System, das Kini noch nicht angebunden hat, hängt der Zeitplan vom Bau dieses Connectors ab. Das sagen wir dir im ersten Gespräch, nicht hinterher.

Nein. Beim Magic-Link-Onboarding gibt dein Endkunde seine ATS-Zugangsdaten selbst über einen Link ein, den du erzeugst. Du siehst sie also nie. Bei manchen Systemen muss der ATS-Admin oder der Anbieter des Kunden die Zugangsdaten erst anlegen, zum Beispiel einen API-Key oder ein Zertifikat. Hast du bereits Zugangsdaten, kannst du sie selbst eingeben, allein oder gemeinsam mit dem Kunden in einem Call.

Das ist nicht nur technisch, sondern auch kaufmännisch wichtig. Einen Kunden um Admin-Zugangsdaten zu bitten, bremst Deals aus. Ihn zu bitten, einen Link anzuklicken und die Verbindung im eigenen System freizugeben, meist nicht. Außerdem fällt dein Unternehmen so nicht unter seine Richtlinien für Zugangsdaten.

Ein Magic Link ist ein Link, den du an einen Endkunden schickst, damit er sein ATS selbst verbinden kann. Die Zugangsdaten gehen direkt an Kini und berühren deine Systeme nie. Für viele ATS gibt es Einrichtungsanleitungen mit Screenshots, und auf Wunsch sind wir bei Onboarding-Calls dabei.

Der andere Weg bleibt offen: Hast du die Zugangsdaten eines Kunden schon, gibst du sie im selben Assistenten selbst ein, allein oder gemeinsam mit dem Kunden in einem Call. Beide Wege führen zum selben Ergebnis: ein verbundenes Unternehmen, das du anschließend in deinem Workspace verwaltest.

Weniger Leute, als die meisten Teams erwarten. Dein Endkunde verbindet sein ATS selbst über den Magic Link, dort fällt also keine Entwicklungsarbeit an. Bei dir reicht ein technischer Ansprechpartner für API-Key und Webhook-Endpunkt. Kini hat Einrichtungsanleitungen für viele ATS und ist auf Wunsch bei Onboarding-Calls dabei.

Der größere Aufwand ist meist kaufmännisch, nicht technisch: zu entscheiden, welche Kunden zuerst angebunden werden und wie du ihnen die Integration präsentierst. Genau dafür sind das Erstgespräch und der Pilot da.

Mapping und Datenanreicherung passieren bei Kini. Du integrierst also in dem Format, das für dich ohnehin passt. Wir mappen ins Zielformat, reichern Daten an und kümmern uns um Screening-Fragen. Braucht ein Partnersystem einen eigenen Connector, bauen wir ihn, statt dich um Anpassungen zu bitten.

Das gilt auch dafür, wie du Daten lieferst: API, XML-Feed oder JSON-Feed funktionieren gleichermaßen. Die Anpassung passiert einmal im Connector statt immer wieder in jedem Kundenprojekt.

Beides. Der Onboarding-Assistent bietet zwei Wege: Du gibst die Zugangsdaten selbst ein, allein oder mit dem Kunden in einem Call, oder du schickst einen Magic Link und lässt den Kunden das erledigen. Die Partnerschaft startet begleitet mit einem Gespräch. Danach lädst du Kunden selbst ein, und Kini prüft und aktiviert jede neue Verbindung.

Ziel ist, dass der begleitete Teil nur einmal stattfindet. Nach dem Pilot soll ein Account Manager einen Kunden hinzufügen können, ohne auf einer der beiden Seiten die Entwicklung einzubeziehen.

Manchmal. Bei einigen Systemen muss der ATS-Anbieter oder der ATS-Admin des Kunden zuerst einen Schritt erledigen, zum Beispiel API-Zugangsdaten ausstellen, ein Zertifikat einrichten oder Kini freischalten. Kini bereitet diese Anfragen für dich vor, danach verbindet sich der Kunde über den Magic Link.

Schick eine Testbewerbung auf eine aktive Stelle, mit eindeutigem Namen und eindeutiger E-Mail-Adresse, damit das ATS sie nicht als Dublette ablehnt. Kini prüft das Ergebnis in den Logs. Zeigt der Test ein Problem im Setup, etwa eine falsche Base-URL, korrigiert Kini es und synchronisiert den Kandidaten erneut.

Öffne den Kunden in der Partner App, erzeuge einen neuen Magic Link und schick ihn an den Kunden. Er gibt die neuen Zugangsdaten ein, und die Verbindung läuft weiter. Für SAP SuccessFactors stellt Kini auf Anfrage ein neues Zertifikat aus.

Über Kini. Stellen werden aus Personio gelesen, auf die Pflichtfelder von StepStone gemappt und über Kini Shop veröffentlicht.

Die Arbeit steckt in der Übersetzung. Personio bildet eine Stelle auf eine Art ab, StepStone erwartet eine andere, und keine Seite passt sich der anderen an. Ein gepflegter Connector fängt diesen Unterschied ab, auch wenn Personio seine API ändert.

Indeed schickt jede Bewerbung an Kini. Dort wird sie in das Format umgewandelt, das das ATS erwartet, und als Kandidat angelegt. Es kommt an, was Indeed liefert: Kontaktdaten, Lebenslauf, optional ein Anschreiben und Antworten auf unterstützte Screening-Fragen. Jeder Datensatz hat einen Sync-Status. Eine gescheiterte Übergabe ist also sichtbar und geht nicht still verloren.

Die Normalisierung wird leicht unterschätzt. Screening-Fragen unterscheiden sich je Stelle, Anhänge kommen in verschiedenen Formaten, und das Ziel-ATS validiert streng. Geht dabei etwas schief, bekommt der Recruiter keine Fehlermeldung. Er bekommt einen Kandidaten, der nie auftaucht.

Ja. Stellen werden einmal aus dem ATS gelesen und an die Jobbörsen verteilt, die du buchst, jeweils mit den passenden Pflichtfeldern. Über Kini Shop buchst du Anzeigen auf jeder von 1.500+ Jobbörsen oder schaltest mehrere Stellen als Kampagne auf Plattformen wie Indeed.

Veröffentlichen ist nur die halbe Arbeit. Jobbörsen melden auch zurück (veröffentlicht, Veröffentlichung fehlgeschlagen, abgelaufen), und diese Zustände müssen in deinem System ankommen, damit niemand annimmt, eine Anzeige sei live, obwohl sie es nicht ist. Kini sendet sie als Booking-Status-Events.

Kini Core verbindet 65+ ATS sowie Jobbörsen, Social-Recruiting- und Screening-Tools. Zu den unterstützten ATS gehören Personio, softgarden, d.vinci, SAP SuccessFactors, onlyfy, rexx, HR WORKS, zvoove, coveto und GuideCom. Die aktuelle Liste steht auf der Integrationsseite.

Die Abdeckung ist bewusst kuratiert statt vollständig. Jeder Connector bringt ein Standard-Mapping für sein System mit. Das macht ihn ohne Konfiguration nutzbar und macht einen neuen Connector zu echter Arbeit statt zu einem Häkchen.

Es gibt drei Optionen. Wir bauen einen eigenen Connector zu deinem System, und das Mapping liegt bei uns. Du bindest dich über die Kini API mit unserer öffentlichen Doku an. Oder du lieferst Stellen als XML- oder JSON-Feed. Ein fehlendes System kannst du auch direkt in der App über die Systemauswahl anfragen.

Das Prinzip dahinter: Kini passt sich deinem Setup an, statt ein bestimmtes Format von dir zu verlangen. Das ist ein bewusster Unterschied zu reinen API-Anbietern, bei denen die Integration so gebaut werden muss, wie der Anbieter es erwartet.

Über Kini Shop. StepStone, Indeed, XING, meinestadt und viele regionale Jobbörsen lassen sich dort buchen, und die Pflichtfelder und Veröffentlichungsregeln jeder Jobbörse sind bereits berücksichtigt. Insgesamt bietet Kini Shop Zugang zu 1.500+ Jobbörsen.

An DACH-Jobbörsen scheitern generische internationale Tools oft: andere Kategorien, andere Pflichtfelder und Veröffentlichungsregeln, die sich ohne große Vorankündigung ändern. Das ist regionale Spezialisierung, keine Übersetzungsschicht.

Ja. Die Kini API ist öffentlich und auf docs.getkini.com dokumentiert. Die Authentifizierung läuft über Bearer-API-Keys, die du in der Partner App mit Ablaufdatum anlegst und selbst widerrufst. Stellen sendest du mit POST /jobs, Bewerbungen werden über dieselbe API übermittelt und nachverfolgt.

Anfragen gelten jeweils für ein verbundenes Unternehmen, festgelegt über einen Company-Id-Header. So kann ein einziger Key alle deine Kunden bedienen, und ihre Daten bleiben trotzdem getrennt. Auch Rate Limits gelten pro Unternehmen, nicht pro Partner.

Standardmäßig gehen Stellen vom ATS hinaus zu deinen Kanälen, und Bewerbungen kommen zurück ins ATS des Kunden. Bei manchen ATS kann Kini auch Bewerbungen aus dem ATS lesen und an andere Systeme weitergeben.

Welche Richtung zählt, hängt vom Partner ab: Eine Jobbörse übernimmt Stellen und liefert Bewerbungen zurück, ein ATS-Anbieter bringt seine Stellen in Kanäle und bekommt Bewerbungen zurück.

Jeder Connector bringt ein Standard-Mapping für die Felder seines Systems mit, die meisten Setups funktionieren also ohne Konfiguration. Weicht das Setup eines Kunden ab, passt das Kini-Team das Mapping an. Mapping und Anreicherung bleiben bei Kini, statt zu deinem Problem zu werden.

Am schwierigsten ist meist das Mapping von Auswahlwerten und Status, weil zwei ATS einen Einstellungsprozess selten gleich abbilden. Standard-Mappings pro Connector gibt es, damit das einmal gelöst wird und nicht für jeden Kunden neu.

Das hängt vom ATS ab. Kini übergibt mit jeder Bewerbung eine Quelle, zum Beispiel den Namen der Jobbörse, und jedes System geht damit anders um. Manche ATS akzeptieren nur Quellen, die dort schon angelegt sind. Diese müssen dann vor dem Go-live eingerichtet werden.

Standardmäßig liefert Indeed Kontaktdaten, den Lebenslauf und optional ein Anschreiben, und Kini gibt sie an das ATS weiter. Weitere Dokumente lassen sich in der Bewerbung abfragen. Adressdaten gehören nicht zu den Standarddaten von Indeed. Wenn du sie brauchst, fragst du sie am zuverlässigsten über eine Pflicht-Screening-Frage ab.

Beides, je nach Richtung. Kini holt Stellen standardmäßig einmal pro Stunde aus einem verbundenen ATS, das Crawlen von Karriereseiten läuft genauso. Das Intervall wird pro Unternehmen festgelegt und lässt sich nach Absprache verkürzen. Bewerbungen gehen ans ATS, sobald sie eingehen, und Events (Stelle angelegt, geändert oder archiviert, Sync-Status einer Bewerbung, Booking-Status) sendet Kini per Webhook an deinen Endpunkt.

Die Aufteilung ist bewusst. Ein ATS ständig abzufragen, würde ohne Nutzen an Rate Limits stoßen, während Bewerbungen und Statusänderungen zeitkritisch sind und deshalb aktiv gesendet werden. Brauchst du eine Stellenänderung schneller als im Zeitplan, meldet dir der Job-Updates-Webhook sie in dem Moment, in dem sie passiert.

Auf vier Wegen. Du sendest sie per API mit POST /jobs, Kini holt sie nach Zeitplan aus dem verbundenen ATS, Kini crawlt die Karriereseite des Unternehmens, oder jemand legt sie in der Kini App von Hand an.

Das Crawlen von Karriereseiten ist wichtiger, als es klingt: Es deckt Unternehmen ab, deren ATS keine nutzbare API hat, und das ist im DACH-Mittelstand ein relevanter Anteil. Für dich funktionieren diese Stellen wie solche aus der API.

Ausgehend: Stellen, inklusive ihrer Bewerbungsformularfelder und stellenspezifischen Screening-Fragen. Eingehend: Bewerbungen mit Antworten und Anhängen, geliefert ins ATS des Kunden. Jede Bewerbung hat außerdem einen Sync-Status.

Bei den Screening-Fragen lohnt sich Planung. Sie werden pro Stelle definiert und können sich nach der Veröffentlichung ändern. Ein Bewerbungsformular, das sie zwischenspeichert, schickt deshalb irgendwann Antworten auf Fragen, die es nicht mehr gibt.

Die API ist nicht idempotent: Jeder POST legt einen neuen Datensatz an. Schick deshalb bei jeder Übermittlung deine eigene partner_application_id mit und prüf sie, bevor du es erneut versuchst. Lehnt das ATS des Kunden einen bereits bekannten Kandidaten ab, markiert Kini die Bewerbung als EXPECTED_FAILURE mit failure_error DuplicateApplicationError, statt sie als echten Fehler zu behandeln.

Diese Unterscheidung hält dein Monitoring ehrlich. Eine Dublette ist ein erwartetes Ergebnis, keine kaputte Integration, und wer beides vermischt, ignoriert irgendwann sein Fehler-Dashboard. Lies immer failure_error und nicht nur den Status, denn EXPECTED_FAILURE deckt auch Fälle ab wie eine Stelle, die nicht mehr veröffentlicht ist.

Es ist gemanagt. Connectors bringen pro System ein Standard-Mapping mit, die meisten Setups brauchen also keine Änderungen. Weicht das Setup eines Kunden ab, passt das Kini-Team das Mapping für dich an.

So ist es gedacht: Die Standards machen Anpassungen zur Ausnahme, und wenn doch eine nötig ist, passiert sie bei Kini statt in deinem Code.

Darum kümmert sich Kini. Ändert ein Anbieter seine API inkompatibel, aktualisiert Kini den Connector, sodass sich auf deiner Seite der Integration nichts ändern muss. Rate Limits und Eigenheiten der einzelnen Connectors werden im Hintergrund behandelt. Weder du noch deine Endkunden müssen sie im Blick behalten.

Genau diese laufenden Kosten unterschätzen selbst gebaute Integrationen. Anbieter ändern Felder, kündigen Endpunkte ab und verschärfen ihre Validierung nach eigenem Zeitplan. Jede dieser Änderungen ist für irgendwen ein kleiner Ausfall, wenn sie nicht vorher jemand abfängt.

Ja, pro Datensatz. Jede Bewerbung trägt ihren letzten Sync-Status (SUCCESS, SUCCESS_FALLBACK, FAILURE, EXPECTED_FAILURE oder NOTSENT) plus einen failure_error zur Diagnose. In der App siehst du Sync-KPIs pro Kunde und einen Status pro Datensatz. Programmatisch fragst du GET /applications ab oder abonnierst den Webhook.

Fragt ein Kunde, was mit einem bestimmten Kandidaten passiert ist, ist die Antwort ein Status mit Grund statt einer Suche in Logs. Kini speichert den letzten Status pro Bewerbung, keine vollständige Historie aller Versuche.

Änderungen gehören ins ATS. Es ist das Quellsystem, und jedes Update schickt die komplette Anzeige neu, deshalb werden Änderungen direkt auf der Jobbörse überschrieben. Aktualisiert das ATS eine Stelle automatisch und vergibt dabei eine neue ID, kann sie aus einer laufenden Kampagne fallen, die an diese ID gebunden ist.

Eine Frage, die du vor der Unterschrift stellen solltest. Bei Eigenbau und Unified APIs lautet die Antwort meist: du. Bei einem Managed-Layer sollte es vertraglich geregelt sein: Monitoring, Wiederholungsversuche und Connector-Updates beim Anbieter, plus ein Status pro Datensatz, den du prüfen kannst, statt eines Versprechens, dem du vertrauen musst.

Der Praxistest: Was passiert montags um 9 Uhr, wenn eine Jobbörse am Wochenende ein Pflichtfeld geändert hat? Entweder repariert es schon jemand, oder dein Support erfährt es von einem Kunden.

Monitoring und Wiederholungsversuche sind Teil des Produkts, kein Zusatz. Fehlgeschlagene Syncs werden automatisch wiederholt und behalten einen eindeutigen Status, statt still verworfen zu werden. Hilft das nicht, schaut sich jemand aus dem Kini-Team den Fall an.

Das Prinzip: Nichts verschwindet unbemerkt. Ein Datensatz, der nicht zugestellt werden konnte, behält einen sichtbaren Zustand und einen Grund. Dadurch wird die Wiederherstellung zur Entscheidung statt zur Spurensuche.

Jede Bewerbung hat einen sichtbaren Status. In der App siehst du Status-Pills pro Datensatz wie Notsent und Failure, Sync-Icons pro Kunde und ein Dashboard mit Sync-KPIs. Programmatisch kommt dieselbe Information über den Application-Sync-Status-Webhook oder per Abfrage von GET /applications.

Der Status gilt bewusst pro Datensatz und nicht pro Integration. Eine Integration, die „läuft“, während einzelne Kandidaten still scheitern, ist genau der Fehlerfall, der Partner ihre Kunden kostet.

Ja, die App hat pro Kunde einen manuellen Re-Sync. Für die automatische Behandlung liefert der Application-Sync-Status-Webhook den failure_error, damit dein System reagieren kann. Eine Einschränkung: Ein 400-Validierungsfehler schlägt unverändert wieder fehl, also korrigier den Payload, bevor du ihn erneut sendest.

Auch auf deiner Seite lohnt es sich, Wiederholungen zu planen. Läuft eine Übermittlung in einen Timeout, prüf über die partner_application_id, ob die Bewerbung schon existiert, bevor du sie erneut sendest. Die API legt bei jedem POST einen neuen Datensatz an.

Über Webhooks. Job Updates werden bei Anlage, Änderung und Archivierung ausgelöst. Application Sync Status meldet die Zustellung ins ATS. Job Booking Status deckt BOOKED, PROCESSING, PUBLISHED, PUBLISH_FAILED, UNPUBLISHED und EXPIRED ab, mit einer transaction_id zur Nachverfolgung. Schick deinen Endpunkt an tech@getkini.com, um sie zu aktivieren.

Benachrichtigungen zu Stellen schätzen Partner meist am meisten: Du erfährst, wenn ein Endkunde eine Stelle veröffentlicht, ändert oder schließt, ohne jedes ATS regelmäßig abzufragen.

Ja: 60 Anfragen pro Minute pro verbundenem Unternehmen, erkannt an der company_id in der Anfrage. Das Limit gilt für jeden deiner Kunden einzeln, zehn verbundene Unternehmen haben also zehn getrennte Budgets. Einige Endpunkte weichen ab, das steht in der API-Referenz.

Limits pro Unternehmen bedeuten, dass dein Durchsatz mit deinem Kundenstamm wächst, statt an eine gemeinsame Obergrenze zu stoßen. Es heißt aber auch, dass sich eine Massenoperation für einen Kunden nicht auf die anderen verteilen lässt.

Jedes verbundene Unternehmen hat seine eigene company_id, und die Partner App zeigt einen Unternehmenswechsler sowie eine Kundentabelle mit Zuständen wie Active, Invited und Requested. Sync-Icons in dieser Liste zeigen auf einen Blick, ob die Verbindung jedes Kunden in Ordnung ist.

Für Personalvermittlungen und Plattformen mit Dutzenden Endkunden ist diese Liste die eigentliche tägliche Oberfläche: Sie zeigt, wer live ist, wer eingeladen wurde, aber noch nicht verbunden hat, und wo etwas Aufmerksamkeit braucht.

Jeder Zustellversuch löst ein eigenes Webhook-Event aus. Auf einen Fehler mit anschließend erfolgreichem Wiederholungsversuch folgen also zwei Events. Nimm immer das neueste Event einer Bewerbung und überschreib den vorherigen Status.

Breaking Changes kündigen wir Partnern vorab an, damit du deine Integration rechtzeitig anpassen kannst. Alle anderen Änderungen, etwa neue Endpunkte, Felder oder Webhook-Events, dokumentieren wir in der API-Dokumentation.

Kann sie sein, aber Compliance entsteht durch das Setup, nicht durch die Verbindung selbst. Achte auf EU-Hosting, einen vor dem Go-live unterschriebenen Auftragsverarbeitungsvertrag (AVV), eine festgelegte Aufbewahrungsfrist und klare Regeln, wer was löscht. Kini wird in Frankfurt gehostet und löscht oder anonymisiert personenbezogene Bewerberdaten 180 Tage nach Anlage einer Bewerbung.

Die Frage nach der Aufbewahrung wird am häufigsten übersprungen. Eine Integration, die Kandidatendaten unbegrenzt speichert, macht jeden Partner unbemerkt zum langfristigen Verantwortlichen für Daten, die er nicht mehr braucht. Genau das soll Datenminimierung verhindern.

Bewerbungen enthalten ausführliche personenbezogene Daten, und jede Übermittlung außerhalb der EU braucht eine Rechtsgrundlage, die dein Einkauf vertreten muss. Hosting in der EU erspart diesen Schritt. Die Plattform von Kini läuft in Frankfurt am Main, eine Übermittlung in Drittländer gehört nicht zum Standard-Setup.

Für Käufer im DACH-Raum ist das oft ein hartes Kriterium und keine Vorliebe: Es entscheidet, ob ein Anbieter überhaupt auf die Shortlist kommt, bevor jemand auf Funktionen schaut.

Kinis Plattform und Datenbank laufen auf Google Cloud in Frankfurt, Daten werden bei der Übertragung und im Ruhezustand verschlüsselt. Kini löscht oder anonymisiert personenbezogene Bewerberdaten 180 Tage nach Anlage einer Bewerbung.

Die Aufbewahrung hängt vom Feld ab: Reporting-Felder wie Stelle, Kanal, Status und Zeitstempel bleiben verfügbar, personenbezogene Bewerberdaten werden nach festem Zeitplan entfernt.

Ja. Kini arbeitet nach der DSGVO und stellt vor Vertragsabschluss eine AVV-Vorlage bereit, damit deine rechtliche Prüfung schon vorher beginnen kann. Fragen zu Sicherheit und Datenverarbeitung sollen sich ohne Sales-Call beantworten lassen.

Den AVV früh zu verschicken, ist Absicht: In den meisten Partnerschaften läuft die rechtliche Prüfung parallel zum technischen Pilot, und eine Vorlage, die spät kommt, verzögert am Ende den Go-live.

Bewerbungen werden 180 Tage nach ihrer Anlage automatisch anonymisiert. Personenbezogene Felder (Kandidatendaten, Anhänge, Notizen, Social-Media-Links, Screening-Antworten, benutzerdefinierte Felder) fehlen dann vollständig in den API-Antworten. Reporting-Felder wie Stelle, Kanal, Status und Zeitstempel bleiben unbegrenzt verfügbar.

Zwei praktische Folgen: Übertrag alle Kandidatendaten, die du brauchst, innerhalb dieser Frist in dein eigenes System. Und behandle die personenbezogenen Felder in deiner Integration als optional, denn nach 180 Tagen fehlen die Keys, statt leer zu sein. Filter auf die E-Mail-Adresse finden anonymisierte Datensätze ebenfalls nicht mehr.

Zugangsdaten werden pro Endkunde in Kini Core verwaltet, als verschlüsselte Secrets gespeichert und nie von der API zurückgegeben. Beim Magic-Link-Onboarding gibt der Kunde sie direkt ein, sie laufen also nie durch deine Systeme. Deine API-Keys sind davon getrennt: Du legst sie mit Ablaufdatum an und widerrufst sie selbst in der Partner App.

Weil beides getrennt ist, kann ein Partner einen Kunden abmelden, ohne auf seiner Seite etwas zu rotieren, und seinen eigenen Key widerrufen, ohne Kundenverbindungen anzufassen.

Nein. Kundendaten werden nicht für das Training von KI-Modellen verwendet.

Das hängt vom Modell ab. Beim Eigenbau sind es Entwicklungszeit plus laufende Pflege pro Connector. Bei einem Managed-Anbieter ist es meist eine wiederkehrende Gebühr, die an eine Kennzahl gekoppelt ist. Bei Kini ist das die Zahl der integrierten Endkunden, ohne Einrichtungsgebühr. Die aktuellen Preise findest du auf der Preisseite.

Überraschend für viele Teams ist das zweite Jahr, nicht das erste. Bauen passiert einmal. Eine wachsende Zahl von Connectors zu pflegen, ist ein dauerhafter Posten, und der wächst mit den Kunden, nicht mit dem eingesparten Aufwand.

Nichts davon. Kini Core wird pro integriertem Endkunden abgerechnet, eine einzige Achse, und in höheren Stufen sinkt der Preis pro Endkunde. Kini Shop hat eine monatliche Gebühr plus eine Margenteilung auf den Shop-Umsatz. Die Stufen (Lite, Basic, Grow und Enterprise) und ihre Preise findest du auf der Preisseite.

Eine einzige Kennzahl ist eine bewusste Entscheidung: Deine Kosten bewegen sich mit dem Nutzen, den du bekommst, nicht mit API-Calls oder Nutzerplätzen, und sie bleiben planbar, auch wenn die Nutzung bei jedem Kunden wächst.

Nein. Wir setzen auf enge Partnerschaften, statt das Onboarding zu berechnen. Die Mindestlaufzeit beträgt zwölf Monate, dazu gibt es eine 30-Tage-Geld-zurück-Garantie: Kündigst du innerhalb von 30 Tagen, brauchst du keinen Grund und zahlst nichts.

Ohne Einrichtungsgebühr liegt das Risiko bewusst bei uns. Außerdem entfällt die Verhandlung, die einen ersten Pilot sonst oft um Wochen verzögert.

Eine einzige Achse. Bei Kini Core ist es die Zahl der integrierten Endkunden, nicht Nutzerplätze oder API-Calls. Die Stufen sind an Mindestvolumen gebunden, und Rabatte gelten auf Integrationsebene. Der Preis pro Kunde sinkt also, wenn du wächst.

Die Abrechnung beginnt, sobald über die Onboarding-App eine Integration für einen Kunden angelegt wird.

Ja. Du kannst während der Laufzeit weitere Integrationen anfragen oder in ein größeres Paket wechseln, und wir erstellen ein neues Angebot auf Basis der Restlaufzeit und dessen, was du bereits gezahlt hast. Reduzierungen sind mit drei Monaten Frist zum Monatsende möglich.

Core und Shop bleiben durchgehend getrennte Produkte: Du kannst eines später hinzunehmen, ohne das andere umzustellen, und keines ist ein Add-on des anderen.

Statt einer Testphase bieten wir eine 30-Tage-Geld-zurück-Garantie: Kündige in den ersten 30 Tagen ohne Angabe von Gründen und ohne zu zahlen. Ein Connectivity-Layer beweist sich erst mit echten Kunden und echten Daten, und das kann ein eingeschränkter Testzugang nicht leisten.

Deshalb gehört der Pilot-Endkunde zum Onboarding und ist kein optionales Extra: Die erste echte Verbindung ist der Test.

Zwölf Monate. Dazu kommt die 30-Tage-Geld-zurück-Garantie, die eigentliche Bindung beginnt also erst, nachdem du die Integration mit deinen eigenen Kunden im Einsatz gesehen hast. Nach der Erstlaufzeit läuft der Vertrag unbefristet weiter, mit drei Monaten Kündigungsfrist.

Eine Einrichtungsgebühr kommt nicht dazu. Die zwölf Monate sind also die gesamte Bindung und nicht nur ihr zweiter Teil.

Monitoring, Wiederholungsversuche und Connector-Pflege sind Teil des Produkts und keine Support-Stufe. Fragen gehen an das Kini-Team unter tech@getkini.com, und je nach Tarif bekommst du zusätzlich einen gemeinsamen Slack-Channel mit der Kini-Entwicklung.

Weil die Connector-Pflege inklusive ist, erledigt Kini viele Probleme, ohne dass du ein Ticket schreiben musst.

Es gilt dieselbe einzige Achse: Du zahlst pro integriertem Endkunden, die Kosten wachsen also mit dem Kundenstamm, den du tatsächlich anbindest. Staffelrabatte gelten auf Integrationsebene, der Preis pro Kunde sinkt also, wenn dein Portfolio wächst.

Personalvermittlungen bekommen außerdem die Funktionen, die für viele Kunden gleichzeitig gebaut sind: einen Unternehmenswechsler, Sync-Status pro Kunde und getrennte Rechnungsdaten inklusive USt-IdNr. und Kostenstelle pro Endkunde.

Ja. Kini Shop steht Unternehmen direkt offen, und die Basisnutzung ist kostenlos: Du zahlst nur die Produkte, die du buchst. Kostenpflichtige Stufen ergänzen die Verwaltung mehrerer Organisationen, eigene ATS-Anbindungen, mehrere Kostenstellen und verhandelte Multiposting-Preise.

Die kostenlose Stufe ist ein echter Einstieg und keine Demo: Du kannst dein ATS verbinden, Stellen veröffentlichen und Bewerbungen empfangen, ohne über einen Vertrag zu sprechen.

Kini Shop gibt dir Zugang zu 1.500+ Jobbörsen, und du buchst jede Anzeige dort, wo sie laufen soll. Du kannst auch mehrere Stellen als Kampagne auf Plattformen wie Indeed schalten, mit einem Budget für die ganze Kampagne.

Die Buchung läuft in vier Schritten: Produkt wählen, Anzeige konfigurieren, Rechnungsdaten eingeben, prüfen. Was eine Anzeige kostet, siehst du, bevor du dich festlegst.

Ja, die direkte Integration mit deinem ATS ist inklusive. Bewerbungen aus gebuchten Kanälen werden normalisiert und zurück in dein ATS geschrieben. Dein System bleibt so das System of Record, und niemand kopiert Kandidaten von Hand.

Das ist der Unterschied zur einzelnen Buchung jeder Jobbörse: Die Anzeige geht über viele Kanäle raus, aber die Bewerbungen kommen an einem Ort und in einheitlicher Form zurück.

Die Basisnutzung des Shops ist kostenlos, du zahlst pro gebuchtem Produkt. Kostenpflichtige Stufen schalten die Verwaltung mehrerer Organisationen, eigene ATS-Anbindungen und eigene Lieferanten frei. Die Add-ons LinkedIn Chrome Extension und Kini Social Media werden nach Nutzern bzw. nach Kandidatenvolumen abgerechnet. Die Preise findest du auf der Preisseite.

Höhere Stufen sind vor allem für Unternehmen mit mehreren einstellenden Gesellschaften oder verhandelten Konditionen bei Jobbörsen gedacht, nicht als Hürde für den Grundablauf.