Was Kini zwischen Bullhorn und deinen Kanälen übernimmt.
In Bullhorn arbeitet eine Agentur mit Job Orders, Kandidat:innen und Job Submissions. Kini liest die Job Orders und schreibt die beiden anderen für alle Endkund:innen, die du anbindest, sodass Recruiter:innen in ihrer gewohnten Pipeline bleiben.
Nur die Job Orders, die eine Agentur ausschreiben will
Bullhorn legt pro Job Order fest, ob sie noch offen ist (isOpen) und ob sie auf einer Jobbörse erscheinen darf (isPublic). Kini veröffentlicht nur Job Orders, die beides erfüllen, und nutzt dabei die öffentliche statt der internen Beschreibung, sodass Kundendetails für Recruiter:innen nie in einem Kanal für Bewerbende landen.
Bewerbende als Bullhorn-Kandidat:innen, bereit für den Desk
Jede bewerbende Person wird zu einer Bullhorn-Kandidat:in mit Vorname, Nachname, E-Mail, Telefon und Adresse, und der Herkunftskanal steht im Quellenfeld des Datensatzes. Recruiter:innen suchen, betreuen und kontaktieren diese Personen wie selbst gefundene Kandidat:innen, ohne etwas aus einer E-Mail abzutippen.
Eine Job Submission auf der gewählten Job Order
Kini verknüpft jede neue Kandidat:in über eine Job Submission mit der Job Order, auf die sie sich beworben hat. Die Bewerbung erscheint dadurch sofort in der Pipeline dieser Job Order, wo Recruiter:innen sie durch die Submission-Status führen, die die Agentur in Bullhorn eingerichtet hat.
Der Lebenslauf am Kandidatendatensatz
Der Lebenslauf und alle weiteren hochgeladenen Dokumente werden als Dateien an die Bullhorn-Kandidat:in angehängt, mit Originalnamen und Dateityp. Recruiter:innen öffnen den Lebenslauf direkt im Kandidatendatensatz statt im Postfach, und die Datei bleibt für jede spätere Submission bei der Person.
Ein Zustellstatus pro Bewerbung, für dich sichtbar
Kini übergibt jede Bewerbung im Hintergrund an Bullhorn und hält das Ergebnis fest. Deine Plattform erfährt es über den Sync-Status-Webhook oder per Abfrage der Kini-API, und sobald eine Bewerbung angekommen ist, liefert Kini die ID aus Bullhorn mit, sodass beide Seiten auf denselben Datensatz verweisen.
Jedes Feld. Jede Entität.Genau dort, wo es hingehört.
Vier Bullhorn-Entitäten sind beteiligt: Job Orders gehen hinaus in deine Kanäle, Kandidat:innen, Job Submissions und Kandidatendateien kommen zurück. Die Feldnamen sind so geschrieben wie in Bullhorns REST-API-Referenz.
Job Orders
Kandidat:innen
Job Submissions
Kandidatendateien
In Bullhorn ist eine Bewerbung kein eigener Datensatz. Eine JobSubmission verknüpft eine Kandidatin oder einen Kandidaten mit einer Job Order, daher schreibt Kini pro Person zwei Datensätze: zuerst die Kandidat:in, dann die Submission.
Schritt 1Verbinden
Schritt 2Mappen
Schritt 3Testen
Schritt 4Go-live!
mit deinem Stack funktioniert?
Häufige Fragen zur Bullhorn Integration.
Welche Job Orders Kini veröffentlicht, wie Bewerbungen in der Bullhorn-Pipeline einer Agentur landen und was die Agentur für die Verbindung bereitstellt.
Job Orders kommen aus Bullhorn, wenn sie offen und öffentlich sind. In die andere Richtung legt Kini pro bewerbender Person eine Kandidat:in an, eine Job Submission, die sie mit der Job Order verbindet, und die hochgeladenen Dateien am Kandidatendatensatz. Job Orders in Bullhorn ändert Kini nicht, es liest sie nur.
Nur Job Orders, die Bullhorn als offen und öffentlich führt. Eine Job Order, die die Agentur intern hält oder die besetzt oder geschlossen ist, bleibt draußen. Ist eine veröffentlichte Job Order nicht mehr offen oder öffentlich, archiviert Kini den Job, und deine Plattform erhält die Änderung über Kinis Job-Updates.
API-Zugang zu ihrem Bullhorn-Konto. Bullhorns REST-API nutzt OAuth 2.0, daher stellt die Agentur eine für ihr Konto ausgestellte Client-ID und ein Client-Secret bereit, zusammen mit Benutzername und Passwort eines Bullhorn-API-Benutzers. Kini speichert diese Zugangsdaten nur für dieses eine Konto.
Weil Bullhorn eine Bewerbung als Job Submission zwischen einer Kandidat:in und einer Job Order abbildet. Der Kandidatendatensatz enthält die Angaben und Dateien der Person, die Submission den Status auf einer bestimmten Stelle. Beide Datensätze sind nötig, damit die Bewerbung in der Pipeline der Job Order erscheint.
Kini hält das Ergebnis fest, statt es zu verwerfen. Eine erwartbare Ablehnung, etwa weil die Job Order nicht mehr veröffentlicht ist, wird als erwarteter Fehlschlag markiert und braucht kein Eingreifen. Jeder andere Fehler ist mit seiner Meldung pro Bewerbung über die Kini-API und den Sync-Status-Webhook sichtbar.
Nein. Bullhorn bleibt das System of Record der Agentur für Job Orders, Kandidat:innen und Platzierungen. Kini sitzt zwischen Bullhorn und den Kanälen, in denen diese Job Orders ausgeschrieben werden, und bringt die Bewerbenden zurück in Bullhorn. Recruiter:innen behalten ihren Desk, ihre Pipeline und ihr Reporting in Bullhorn.
Kini verarbeitet Bewerbungsdaten in der EU, in Frankfurt, und bietet einen Auftragsverarbeitungsvertrag an. Innerhalb von Kini werden Kontaktdaten, Anhänge, Notizen und Screening-Antworten 180 Tage nach Eingang aus einer Bewerbung entfernt. Was Kini in Bullhorn geschrieben hat, bleibt dort unter der Kontrolle der Agentur.
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.“
