// stack · schnittstelle
Personio ist eine HR-Software aus München — mit einem Bewerbermanagement, in dem offene Stellen entstehen und Bewerbungen zusammenlaufen. Damit diese Stellen nicht nur unter einer fremden Adresse stehen, holt siteway sie über den XML-Feed oder die Recruiting-API auf deine eigene Karriereseite: im eigenen Design, maschinenlesbar ausgezeichnet — und mit einem Bewerbungsweg zurück ins System.
// definition
Personio ist eine cloudbasierte HR-Software aus München, die Personalprozesse kleiner und mittelständischer Unternehmen an einer Stelle bündelt. Personalverwaltung, Abwesenheiten, Zeiterfassung und Auswertungen gehören dazu — und ein Bewerbermanagement, im Fachjargon ein ATS: Applicant Tracking System. Gegründet wurde das Unternehmen 2015 in München.
Für deine Website ist genau dieser Recruiting-Teil relevant. Dort legt die Personalabteilung eine Stelle an, veröffentlicht sie, und dort laufen später die Bewerbungen ein und durchlaufen ihre Phasen. Personio kann dafür eine eigene, gehostete Karriereseite ausspielen — die liegt dann aber unter einer Adresse des Anbieters, nicht unter deiner. Der interessante Teil beginnt an der Stelle, an der beide Seiten miteinander reden.
Dafür bietet Personio zwei Wege an: einen XML-Feed mit den veröffentlichten Stellen und eine Recruiting-API, die zusätzlich Bewerbungen entgegennimmt. Diese Seite beschreibt beide Wege und wie wir sie in einer Website verdrahten. Andere Systeme aus demselben Feld — etwa rexx systems — binden wir nach demselben Muster an; das Prinzip ändert sich nicht, nur die Feldnamen.
// praxis
personio pflegt · deine seite zeigt
Der Grundsatz ist immer derselbe: Personio bleibt die führende Quelle, die Website bleibt die Bühne. Niemand pflegt eine Stelle zweimal. Die Personalabteilung arbeitet weiter in der Oberfläche, die sie kennt; deine Karriereseite holt sich den Stand ab und stellt ihn so dar, wie der Rest der Website aussieht — mit deiner Typografie, deinen Farben, deinen Filtern.
Technisch läuft das in fünf Schritten. Abholen: Ein Job im Hintergrund ruft Feed oder API in festem Takt ab, statt bei jedem Seitenaufruf. Zwischenspeichern: Das Ergebnis landet im Cache, damit die Karriereseite auch dann steht, wenn die Gegenstelle einmal nicht antwortet. Mappen: Jedes Feld bekommt seinen Platz im CMS — Titel, Standort, Abteilung, Anstellungsart, Beschäftigungsumfang, Beschreibung. Darstellen: Stellenliste mit Filtern und eine eigene Detailseite je Stelle. Auszeichnen: JobPosting-JSON-LD, damit die Stelle maschinenlesbar wird.
Der Rückweg ist der zweite Teil der Anbindung. Entweder verlinkt die Detailseite auf das Bewerbungsformular von Personio — schnell gebaut, aber der Bewerber wechselt mitten im Prozess die Oberfläche. Oder das Formular steht auf deiner Domain und übergibt die Bewerbung samt Anhängen per API. Beide Varianten sind sauber; sie unterscheiden sich in Aufwand und Durchgängigkeit. Die Anbindung selbst gehört zur Leistung Schnittstellen & Integration, die Karriereseite drumherum zur Komponente Job- & Karriereportal.
// weg aöffentlich
Personio stellt die veröffentlichten Stellen als XML-Datei bereit — laut offizieller Schnittstellenbeschreibung unter der jobs-Adresse des Accounts, wahlweise in mehreren Sprachen über einen Parameter. Kein Schlüssel, keine Anmeldung, ein Abruf. Das ist der kürzeste Weg zu einer eigenen Stellenliste und trägt, solange die Website nur anzeigen soll.
passt, wenn: stellen zeigen reicht
// weg bauthentifiziert
Der authentifizierte Weg: Die Schnittstelle liefert offene Stellen und nimmt umgekehrt Bewerbungen entgegen — inklusive eines eigenen Aufrufs für Dateianhänge. Dafür braucht es Zugangsdaten aus dem Personio-Account und einen Server, der sie hält. Der Weg lohnt, sobald der Bewerbungsweg auf deiner Domain enden soll.
passt, wenn: bewerbung bei dir endet
In vielen Projekten steht am Ende eine Mischung: Stellen kommen über den Feed, die Bewerbung geht über die API. Das ist keine Verlegenheitslösung, sondern die Kombination mit dem besten Verhältnis von Aufwand zu Wirkung. Was zu dir passt, klären wir im Konzept — vor dem Bauen, mit Begründung.
// bausteine · 6 details
jeder mit klarem zweck
Zwischen „Stelle in Personio angelegt“ und „Bewerbung liegt wieder in Personio“ stehen sechs Teile. Das sind sie — und wofür jeder gebraucht wird.
// d-01quelle
Ein Job im Hintergrund fragt Feed oder API in festem Takt ab und legt das Ergebnis ab. Kein Besucher wartet auf ein fremdes System, und wenn die Gegenstelle einmal schweigt, zeigt die Seite den letzten guten Stand statt einer Fehlermeldung.
zweck: stabiler abruf
// d-02modell
Der Feed liefert unter anderem Kennung, Gesellschaft, Standort, Abteilung, Kategorie, Stellenbezeichnung, Anstellungsart, Erfahrungsniveau, Beschäftigungsumfang und die Beschreibungsabschnitte. Jedes dieser Felder bekommt seinen Platz im CMS — festgelegt, bevor die erste Zeile Template entsteht.
zweck: felder mit platz
// d-03darstellung
Die Übersicht filtert nach Standort, Abteilung und Anstellungsart — genau die Werte, die der Feed ohnehin mitbringt. Jede Stelle bekommt eine eigene, sprechende Adresse, die man verlinken, teilen und indexieren kann.
zweck: eine url je stelle
// d-04hygiene
Verschwindet eine Stelle aus dem Feed, verschwindet sie aus der Liste. Die Adresse braucht trotzdem eine Regel: Gültigkeitsdatum in der Vergangenheit, Status 404 oder 410, oder Markup entfernen. Wir legen das fest, statt es dem Zufall zu überlassen.
zweck: keine karteileichen
// d-05rückweg
Über die Recruiting-API nimmt Personio Bewerbungen entgegen: Vorname, Nachname, E-Mail und die Kennung der Stelle sind Pflicht. Anhänge werden zuvor über einen eigenen Aufruf hochgeladen — die Schnittstellenbeschreibung nennt 20 MB je Datei als Obergrenze — und dann zugeordnet.
zweck: bewerbung ohne umweg
// d-06zugang
Personio unterbindet Aufrufe direkt aus dem Browser bewusst, damit Schlüssel nicht im Frontend landen. Die Anbindung läuft deshalb über einen eigenen Endpunkt auf deinem Server — dieselbe Bauweise, die wir in allen Anbindungen nutzen.
zweck: schlüssel bleiben hinten
// integration
ein muster · drei systeme
Die Anbindung an Personio bauen wir selbst — mit den Bordmitteln, die das jeweilige System dafür mitbringt. Das Muster ist in allen dreien dasselbe: Ein Job im Hintergrund holt den Stellen-Feed in festem Takt, und jede Stelle wird dabei ein eigener Inhalt im CMS — mit eigener, sprechender Adresse, nicht als Kachel in einer eingebetteten Liste. Das Frontend rendert daraus dreierlei: die Übersicht, die Filter und die Detailseite. Und aus denselben Feldern, die dabei ohnehin durchlaufen, entsteht das JobPosting-Markup: Der Personio-XML-Feed liefert es nicht mit, es entsteht erst bei uns im CMS — genau deshalb ist die eigene Anbindung die tragfähige Lösung.
Im CMS liegt dafür ein kleines Datenmodell: Kennung, Titel, Standort, Abteilung, Anstellungsart, Beschäftigungsumfang und die Beschreibungsabschnitte, dazu die Felder, die aus dem Personio-Konto nicht kommen und redaktionell entstehen — Gültigkeitsdatum, Gehaltsrahmen, Ansprechpartner, ein Bild fürs Teilen. Der Cache liegt eine Ebene darunter und hält die Karriereseite auch dann aufrecht, wenn die Gegenstelle einmal schweigt. Das Bewerbungsformular setzt zuletzt an der Detailseite an: Es kennt die Kennung der Stelle und reicht die Bewerbung serverseitig weiter. Die drei Systeme, mit denen wir arbeiten, unterscheiden sich nur darin, wo wir diesen Import andocken.
// cms · enterpriseextbase
Die Anbindung entsteht als eigene Extension: Extbase als Unterbau, das TCA beschreibt die Stelle als Datenmodell. Den Abruf von Feed oder Recruiting-API hängen wir als Scheduler-Task ein, der im festen Takt läuft; jede Stelle landet als Record in einem eigenen Systemordner. Das Site Handling gibt jeder Stelle ihre eigene sprechende URL, Fluid-Templates geben Übersicht, Filter und Detailseite ihre Form — und rendern das JobPosting-Markup aus denselben Feldern. Was der Feed nicht liefert, ergänzt die Redaktion direkt am Record.
zum system →
// cms · verbreitetplugin
Die Anbindung liegt als eigenes Plugin vor, nicht als Code im Theme — so bleibt sie beim Theme-Wechsel bestehen. Die Stelle ist ein Custom Post Type mit eigenen Meta-Feldern; Standort und Abteilung sind eigene Taxonomien und tragen damit die Filter. Die Abholung läuft als geplanter Lauf im festen Takt, eine eigene Permalink-Struktur gibt jeder Stelle ihre Adresse, Template oder Blocks die Darstellung. Das JobPosting-Markup setzt ein Hook in den <head> der Detailseite — aus denselben Feldern, aus denen auch die sichtbare Seite gebaut wird.
zum system →
// cms · flat filelaravel
Statamic läuft auf Laravel, Inhalte sind Entries in Collections — der Unterbau kommt der eigenen Anbindung also entgegen. Ein Artisan-Command holt Feed oder API ab und schreibt je Stelle einen Entry in die Stellen-Collection; der Scheduler von Laravel ruft ihn im Takt auf. Das Blueprint legt die Felder als Datenmodell fest, Antlers und Blade bauen Liste, Filter, Detailseite und das JobPosting-Markup aus denselben Daten, Static Caching liefert das Ergebnis anschließend statisch aus. Die Redaktion ergänzt Gehalt, Ansprechpartner oder ein Teaserbild am Entry — genauso wie an jeder anderen Seite.
zum system →
// sichtbarkeit
daten kommen · auszeichnung entsteht
Das ist der Punkt, an dem viele Anbindungen auf halbem Weg stehen bleiben. Der XML-Feed transportiert Stellendaten — aber keine strukturierten Daten. Der Personio-Support stellt das in der eigenen Community ausdrücklich klar. Wer den Feed also nur ausliest und hübsch darstellt, hat eine schöne Stellenliste und trotzdem keinen Eintrag in der Job-Box über den Suchergebnissen.
Die Auszeichnung entsteht deshalb bei dir, beim Import. Google verlangt für JobPosting mindestens Titel, Beschreibung, Veröffentlichungsdatum, den Arbeitgeber und den Arbeitsort — oder, bei Remote-Stellen, die Angabe, aus welcher Region gearbeitet werden darf. Diese Werte stehen im Feed bereits drin oder lassen sich daraus ableiten; was fehlt, etwa ein Gültigkeitsdatum oder eine Gehaltsangabe, ergänzt die Redaktion im CMS. Wie wir Markup grundsätzlich bauen, steht unter strukturierte Daten, die Regeln der Job-Box im Detail unter Google for Jobs.
Genauso wichtig ist das Abräumen. Eine besetzte Stelle, die weiter in der Job-Box steht, ärgert Suchende und Google gleichermaßen. Drei Wege sind zulässig: das Gültigkeitsdatum in die Vergangenheit setzen, die Adresse mit Status 404 oder 410 beantworten oder das JobPosting-Markup entfernen. Welcher Weg gilt, entscheiden wir beim Aufbau — und bauen ihn in den Import ein, damit später niemand daran denken muss.
// datenschutz
so wenig wie möglich
Ein Lebenslauf verrät mehr über einen Menschen als die meisten Formulare einer Website zusammen: Werdegang, Adresse, Geburtsdatum, oft ein Foto, manchmal Angaben, die niemand hätte fragen dürfen. Deshalb behandeln wir den Bewerbungsweg strenger als jeden anderen. Die Website fragt nur ab, was für die Bewerbung wirklich gebraucht wird — freiwillige Felder sind als solche gekennzeichnet, und eine Einwilligung steht dort, wo sie hingehört, nicht in einer Fußnote.
Technisch heißt das: durchreichen statt sammeln. Der Upload geht verschlüsselt an deinen Server, wird auf Typ und Größe geprüft, an Personio übergeben — und die temporäre Datei wird gelöscht. So entsteht kein zweites Bewerberarchiv, das niemand pflegt und jeder vergisst. Der API-Aufruf läuft ausschließlich serverseitig; Personio unterbindet den direkten Weg aus dem Browser bewusst, damit Zugangsdaten nicht im Quelltext stehen. Mehr zur Bauweise unter Sicherheit & Datenschutz.
Rechtlich gehört ein Auftragsverarbeitungsvertrag mit Personio dazu, dazu klare Löschfristen für abgelehnte Bewerbungen. In der Praxis orientieren die sich an den Fristen des Allgemeinen Gleichbehandlungsgesetzes, weshalb viele Unternehmen Unterlagen einige Monate nach der Absage aufbewahren und dann löschen. Welche Frist bei dir gilt, legt deine Rechtsberatung fest — wir bauen sie ein, statt sie offen zu lassen.
Ein Formular, das nur mit der Maus funktioniert, sortiert Menschen aus, bevor jemand ihren Lebenslauf gelesen hat. Deshalb bekommt jedes Feld ein sichtbares, verknüpftes Label, der Datei-Upload lässt sich per Tastatur bedienen, und die Fokusreihenfolge folgt der Leserichtung. Fehlermeldungen stehen am Feld statt gesammelt oben, benennen das Problem im Klartext und werden Screenreadern angesagt — nicht nur rot eingefärbt.
Dazu kommen Kleinigkeiten mit großer Wirkung: Angaben zu erlaubten Dateiformaten und maximaler Größe vor dem Upload statt als Fehlermeldung danach, eine Rückmeldung nach dem Absenden, die ankommt, und keine Zeitbegrenzung, die eine sorgfältig geschriebene Bewerbung verfallen lässt. Wie wir das prüfen, steht unter Barrierefreiheit; die Formularseite selbst gehört zur Leistung Formularstrecken.
// faq
Personio ist eine HR-Software aus München, die Personalprozesse in kleinen und mittelständischen Unternehmen bündelt: digitale Personalverwaltung, Abwesenheiten, Zeiterfassung, Auswertungen — und Recruiting. Der Recruiting-Teil ist ein Bewerbermanagement, ein ATS: Stellen werden dort angelegt, Bewerbungen laufen dort ein und durchlaufen die Phasen bis zur Zusage. Gegründet wurde das Unternehmen 2015. Für deine Website ist nur der Recruiting-Teil interessant — genauer die beiden Wege, auf denen Stellen und Bewerbungen zwischen Personio und deiner Karriereseite wandern.
Es gibt zwei Wege, und sie schließen sich nicht aus. Der XML-Feed ist der einfache: Personio stellt die veröffentlichten Stellen als öffentlich abrufbare XML-Datei bereit, deine Website holt sie ab und zeigt sie im eigenen Design. Die Recruiting-API ist der reichere Weg: Sie liefert die Stellen über einen authentifizierten Aufruf und nimmt zusätzlich Bewerbungen entgegen. Die Faustregel dazu ist kurz. Sollen Stellen nur angezeigt werden, trägt der Feed. Soll die Bewerbung selbst auf deiner Domain stattfinden, kommt die API dazu.
Nicht von allein. Der XML-Feed überträgt die Stellendaten, aber keine strukturierten Daten — das stellt der Personio-Support in der eigenen Community ausdrücklich klar. Damit eine Stelle in Google for Jobs auftauchen kann, braucht sie auf deiner Seite JobPosting-JSON-LD; Titel, Beschreibung, Veröffentlichungsdatum, Arbeitgeber und Arbeitsort sind dabei Pflichtangaben. Genau dieses Markup erzeugt siteway beim Import aus den Feldern des Feeds, sodass jede Stelle eine eigene, ausgezeichnete Adresse auf deiner Domain bekommt.
Ja, über die Recruiting-API. Personio nimmt Bewerbungen per Schnittstelle entgegen: Vorname, Nachname, E-Mail-Adresse und die Kennung der Stelle sind die Pflichtangaben. Anhänge wie Lebenslauf und Zeugnisse werden zuerst über einen eigenen Aufruf hochgeladen und dann der Bewerbung zugeordnet; die offizielle Schnittstellenbeschreibung nennt dafür eine Obergrenze von 20 MB je Datei. Der schlankere Weg ist die Weiterleitung ins Bewerbungsformular von Personio — weniger Aufwand, dafür ein Wechsel der Oberfläche mitten im Bewerbungsprozess. Welcher Weg passt, entscheidet sich daran, wie durchgängig der Auftritt sein soll.
Aus der Liste verschwinden sie von selbst, sobald sie in Personio nicht mehr veröffentlicht sind — dann stehen sie schlicht nicht mehr im Feed. Für Google reicht das nicht. Dort gilt eine abgelaufene Stelle erst als abgeräumt, wenn ihr Gültigkeitsdatum in der Vergangenheit liegt, die Adresse mit Status 404 oder 410 antwortet oder das JobPosting-Markup von der Seite verschwindet. Welcher dieser drei Wege gilt, legt siteway beim Aufbau fest — damit in der Job-Box keine Karteileiche stehen bleibt.
Bewerbungsunterlagen gehören zum Sensibelsten, was eine Website überhaupt anfasst — deshalb lagert bei uns so wenig wie möglich zwischen. Läuft die Bewerbung über die Recruiting-API, reicht die Website sie durch und löscht die temporäre Datei, statt ein zweites Bewerberarchiv aufzubauen. Der Aufruf geschieht ausschließlich serverseitig: Personio verhindert Zugriffe direkt aus dem Browser bewusst, damit die Zugangsdaten nicht im Frontend landen. Dazu kommen Transportverschlüsselung, ein Auftragsverarbeitungsvertrag mit dem Anbieter und Löschfristen, die vorher festgelegt und nicht dem Zufall überlassen werden.
Ja, in allen dreien — das Muster ist dasselbe, nur der Andockpunkt unterscheidet sich. In TYPO3 bauen wir eine eigene Extension: Extbase als Unterbau, das TCA als Datenmodell, der Abruf als Scheduler-Task, jede Stelle als Record in einem Systemordner mit eigener sprechender URL aus dem Site Handling und Fluid-Templates fürs Frontend. In WordPress ist es ein eigenes Plugin statt Code im Theme: die Stelle als Custom Post Type mit eigenen Meta-Feldern, Standort und Abteilung als Taxonomien, die Abholung als geplanter Lauf, eine eigene Permalink-Struktur je Stelle, Template oder Blocks für die Darstellung. In Statamic, das auf Laravel läuft, schreibt ein Artisan-Command im Scheduler je Stelle einen Entry in eine Collection; Blueprint, Antlers und Static Caching erledigen den Rest. Das JobPosting-Markup entsteht in allen drei Fällen erst bei uns im CMS, aus denselben Feldern, aus denen auch die sichtbare Seite gebaut wird — der Personio-Feed liefert es nicht mit.
Ja. Die Anbindung von Bewerbermanagement-Systemen gehört zur Leistung Schnittstellen & Integration, die Karriereseite selbst ist die Komponente Job- & Karriereportal. Diese Seite beschreibt die Technik dazwischen: Abholung, Zwischenspeicher, Feld-Mapping, Darstellung, Auszeichnung und der Rückweg der Bewerbung. Ob die Website auf TYPO3, WordPress, Statamic oder Laravel läuft, ändert am Prinzip nichts — nur an der Stelle, an der der Import andockt.
// womit das zusammenhängt
komponente, sichtbarkeit & leistung
// komponente · buchen
Die Schnittstelle hier, der Baustein dort: Stellenliste, Detailseiten, Filter und Bewerbungsformular in deiner Website. Hier wird gebucht.
zur komponente →
// stack · sichtbarkeit
Was JobPosting-Markup können muss, damit eine Stelle in der Job-Box erscheint — und wie besetzte Stellen wieder verschwinden.
zur technik →
// leistung · buchen
Feld-Mapping, Authentifizierung, Fehlerbehandlung und Monitoring — die Leistung, unter der jede Anbindung entsteht.
zur leistung →
// Stellen aus Personio auf deiner Domain?
Projekt anfragen