Die Personio API verbindet Mitarbeitenden-, Beschäftigungs-, Abwesenheits-, Zeit-, Vergütungs-, Dokument-, Reporting- und Recruiting-Daten mit anderen Systemen. Sie ist aber keine Universalfernbedienung für jeden Personio-Prozess. Entscheidend ist nicht nur, ob ein Endpunkt existiert. Prüfen Sie, ob Objekt, Schreiboperation, Event, Berechtigung und Betriebsmodell zu Ihrem konkreten Anwendungsfall passen.

Auf welche Daten kann die Personio API zugreifen?

Die Personio Schnittstelle ist keine einzelne, einheitliche API. Sie besteht aus v1- und v2-Endpunkten, einer separaten Recruiting API und Webhooks. Welche Daten Sie tatsächlich abrufen oder schreiben können, hängt zusätzlich vom Personio-Paket, den freigegebenen Scopes und den lesbaren Attributen des API-Zugangs ab.

Stand August 2026 beschreibt Personio in der offiziellen Übersicht der Public APIs v1 und v2 als sich ergänzende Versionen. Für bestimmte v1-Endpunkte zu Anwesenheiten und Projekten nennt Personio den 31. Juli 2026 als Deprecation-Datum. Planen Sie neue Integrationen deshalb zuerst mit v2. Nutzen Sie v1 nur gezielt, wenn eine benötigte Operation noch keinen passenden v2-Ersatz hat.

Diese Tabelle ist eine Entscheidungshilfe, keine Ersatzdokumentation für einzelne Schemas. Der aktuelle Personio-Leitfaden zum API-Einstieg weist unter anderem darauf hin, dass Mitarbeitendenattribute freigegeben werden müssen. Custom Attributes liefern ihren aktuellen Wert, aber keine vollständige Historie. Zugangsdaten gehören außerdem in einen Backend-Service und nicht in Browser-Code.

Was kann die Personio Schnittstelle nicht?

Die teuersten Integrationsfehler beginnen mit einer scheinbar logischen Annahme: Wenn ein Prozess in der Personio-Oberfläche möglich ist, muss es für jeden Schritt einen öffentlichen Endpunkt geben. Darauf sollten Sie Ihre Architektur nicht aufbauen.

Die aktuelle Public API zeigt keine allgemeine Schreibschnittstelle für jede Recruiting-Aktion. Gehen Sie nicht ungeprüft davon aus, dass Sie bestehende Bewerbungen durch jede Phase schieben, Interviews terminieren, Scorecards ausfüllen, Nachrichten an Kandidaten senden oder jede Freigabe anstoßen können. Solche Abläufe bleiben teilweise in Personio, laufen über eine Marketplace-Integration oder werden von einem angebundenen Modul mit einer klar begrenzten Übergabe übernommen.

Im Recruiting ist Lesen zudem nicht das Spiegelbild von Schreiben. Die v2-Endpunkte lesen Kandidaten, Bewerbungen, Jobs, Kategorien und Phasenwechsel. Custom Attributes und Tags von Kandidaten und Bewerbungen werden derzeit jedoch nicht zurückgegeben. Der separate Endpunkt zum Erstellen einer Bewerbung kann dagegen Attribute, Tags und Referenzen auf zuvor hochgeladene Dokumente annehmen.

Weitere Grenzen betreffen weniger das Datenobjekt als seine Bedeutung:

• Keine automatische Historie: Der aktuelle Wert eines Mitarbeitendenattributs rekonstruiert keine früheren Zustände.
• Kein universeller Event-Stream: Webhooks reduzieren Polling, melden aber nicht jede denkbare Änderung.
• Keine automatische Datenhoheit: Zwei Systeme mit Schreibzugriff können sich nach einer manuellen Änderung widersprechen.
• Kein Prozesskontext: Ein Status verrät nicht zwingend, welche Richtlinie, Freigabe oder menschliche Entscheidung dahintersteht.
• Keine garantierte Verfügbarkeit: Ein dokumentierter Endpunkt kann ein bestimmtes Paket, Produkt oder Scope voraussetzen.

Testen Sie die Integration mit echten Zugangsdaten in einer sicheren Testkonstellation, bevor Sie die Architektur freigeben. Prüfen Sie Felder, Pagination, Filter, Schreibverhalten, Fehlerantworten und die für Ihren Account aktivierten Scopes an realen Payloads.

Wie beeinflussen Rate Limits und Synchronisation die Architektur?

Für die Personio API gilt nicht ein einziges Rate Limit. Grenzen unterscheiden sich nach API-Generation und Endpunkt. Für die v1-Endpunkte zum Anlegen von Bewerbungen und zum Hochladen von Bewerbungsdokumenten dokumentiert Personio beispielsweise 20 Anfragen innerhalb von 60 Sekunden je Unternehmen. Danach gilt die angegebene Wartezeit. Prüfen Sie vor der Kapazitätsplanung die offizielle Einführung zur Recruiting API.

Eine produktive Personio Integration muss HTTP 429 als erwartbaren Betriebsfall behandeln. Verwenden Sie Backoff mit zufälliger Streuung. Stellen Sie Schreibvorgänge in eine Queue, statt sie zu verlieren. Legen Sie eine Idempotenzstrategie fest. Ein Retry darf keine doppelte Bewerbung, Abwesenheit oder Datei erzeugen.

Alle Daten im Minutentakt vollständig abzufragen, ist selten sinnvoll. Ein robuster Ablauf sieht so aus:

1. Führen Sie einen initialen, paginierten Sync durch und speichern Sie die Personio-IDs.
2. Abonnieren Sie die verfügbaren Webhooks für die relevanten Objekte.
3. Nutzen Sie ein Event als Signal, den verbindlichen Datensatz abzurufen.
4. Lassen Sie einen langsameren Abgleich fehlende oder nicht gemeldete Änderungen finden.
5. Protokollieren Sie Cursor, Aktualisierungszeit, Payload-Hash und Verarbeitungsergebnis.

Definieren Sie die Datenhoheit auf Feldebene. Personio kann Name, Beschäftigungsstatus und Abteilung führen. Das Zeiterfassungssystem kann Rohbuchungen besitzen. Ein Screening-Modul kann Score und Belege verwalten, während die finale Recruiting-Entscheidung in Personio bleibt. Ohne diese Vereinbarung überschreibt eine technisch korrekte Schnittstelle schnell die verlässlichere Information.

Wann ist die Personio DATEV Schnittstelle die richtige Wahl?

Die Personio DATEV Schnittstelle ist nicht bloß ein selbst gebautes Skript auf Basis der allgemeinen Employee API. Sie ist eine zweckgebundene Integration für die deutsche Lohnabrechnung. Die Personio-Dokumentation zur DATEV-Einrichtung unterscheidet den Lohnimportdatenservice von Personio zu DATEV, den Rückweg für Lohnauswertungsdokumente und den automatischen eAU-Abruf.

Nutzen Sie die native Integration, wenn der unterstützte Ablauf zu Ihrer Lohnbuchhaltung passt. Sie berücksichtigt bereits Gesellschaften, Berater- und Mandantennummern, Autorisierung, Lohnattribute und die Zusammenarbeit mit der Steuerkanzlei. Diese Semantik über generische API-Endpunkte nachzubauen, verursacht meist Aufwand ohne strategischen Mehrwert.

Eine eigene API-Schicht kann an den Rändern sinnvoll sein. Sie kann Stammdaten vor dem Abrechnungslauf validieren, Werte für das interne Controlling zusammenführen oder Ausnahmen in eine Freigabe-Queue lenken. Der DATEV-Datenservice bleibt dann die Transportstrecke für die Abrechnung. Die eigene Schicht übernimmt Prüfung und Orchestrierung.

Klären Sie den Monatsprozess gemeinsam mit Payroll und Steuerkanzlei:

• Welche Gesellschaften und welches DATEV-Lohnprogramm gehören in den Scope?
• Welches System führt jedes Stamm- und Vergütungsfeld?
• Wer korrigiert einen abgelehnten oder widersprüchlichen Datensatz?
• Wie kommen Abrechnungsdokumente zurück und zu den Mitarbeitenden?
• Welcher Fallback gilt kurz vor dem Abrechnungsschluss?

Wie passen ATS, Active Sourcing und Screening zusammen?

Hinter dem Begriff „ATS-Integration“ verbergen sich mindestens drei unterschiedliche Muster. Wenn Sie diese vermischen, entsteht ein unnötig breiter und störungsanfälliger Sync.

Von der Karriereseite zu Personio

Der Endpunkt zum Erstellen von Bewerbungen passt zu einer eigenen Karriereseite. Sie sammelt Angaben und Dokumente und legt anschließend eine Bewerbung für einen veröffentlichten Personio-Job an. Validieren Sie das Job-Mapping vor dem Absenden. Laden Sie Dokumente im Backend hoch. Speichern Sie die zurückgegebenen IDs. Eine sichtbare Fehler-Queue ist Pflicht, denn ein erfolgreich ausgefülltes Formular garantiert noch keinen Datensatz im ATS.

Vom Active Sourcing zu Personio

Active Sourcing beginnt, bevor eine Bewerbung existiert. Ein Sourcing-System recherchiert passende Personen, verwaltet Ansprache und Sequenzstatus und übergibt erst interessierte oder vorqualifizierte Profile an das ATS. Dadurch bleibt Prospecting-Rauschen außerhalb von Personio. Ein angebundener People-Search-Prozess oder ein Active-Sourcing-Modul für Personio ist oft sinnvoller, als die gesamte Sourcing-Datenbank in Kandidatenfelder zu kopieren.

Screening neben Personio

Screening benötigt mehr als einen Score. Entscheidend sind Anforderungskriterien, Bewerbungsunterlagen, Belege, Review-Status und ein kontrollierter Rückweg. Bei dokumentenlastigem Eingang können Sie ein angebundenes CV-Screening-Modul mit einer Eigenentwicklung vergleichen. Für strukturierte telefonische Vorqualifizierung kann ein Voice-Interview-Modul die Candidate Experience steuern, während Personio das führende ATS bleibt.

Pressen Sie nicht jedes Zwischenergebnis in Custom Fields. Übergeben Sie das kleinste nützliche Paket: Empfehlung, strukturierte Belege, Link zum Detaildatensatz und einen klaren Entscheidungspunkt für Recruiter. Fehlt eine benötigte Schreiboperation, nutzen Sie eine dokumentierte Übergabe oder Aufgabe. Verkleiden Sie keine Browser-Automation als belastbare Schnittstelle.

Wann ist ein angebundenes Modul besser als eine Eigenentwicklung?

Eine Eigenentwicklung lohnt sich, wenn die Integration einen wirklich unternehmensspezifischen Prozess abbildet. Ein Modul ist häufig wirtschaftlicher, wenn der größte Aufwand in Standardverbindungen, Nutzeroberfläche, Monitoring und laufender API-Pflege steckt.

Paket- und Preisverfügbarkeit müssen Sie immer für Ihren konkreten Account prüfen; Stand August 2026. Personio nennt eine entsprechende Paketberechtigung als Voraussetzung für den eigenen Public-API-Zugang. Ein Drittanbieter-Modul kann zusätzlich Lizenz und Implementierung erfordern. Vergleichen Sie die Gesamtverantwortung: Fachkonzept, Security Review, Entwicklung, Datenmigration, Monitoring, Support und spätere API-Änderungen gehören in dieselbe Rechnung.

Häufig ist eine hybride Architektur sinnvoll. Personio bleibt System of Record. Ein Modul besitzt einen klar abgegrenzten Workflow. Eine Orchestrierungsschicht bewegt nur die erforderlichen Daten. Dieses Muster nutzt auch ein mit Personio verbundener AI Agent. Sie können es ebenso mit einer iPaaS, einem Integrationspartner oder einem internen Service umsetzen.

Was sollten Sie vor der Umsetzung prüfen?

1. Ziel festlegen: Benennen Sie den manuellen Schritt, Fehler oder Zeitverlust, den die Integration beseitigen soll.
2. Objekte und Felder erfassen: Trennen Sie notwendige von lediglich bequemen Daten.
3. Richtung und Hoheit markieren: Lesen, Anlegen, Ändern, Löschen, Event und Source of Truth.
4. Account-Zugang testen: Bestätigen Sie Paket, Feature, Scopes, lesbare Attribute und echte Payloads.
5. Fehler modellieren: Berücksichtigen Sie 401, 403, 422, 429, Timeouts, Duplikate und Teilerfolge.
6. Personenbezogene Daten minimieren: Übertragen Sie nur das Nötige und definieren Sie die Löschung.
7. Einen Ablauf pilotieren: Gleichen Sie Ergebnisse manuell ab, bevor Sie Volumen oder Schreibrechte erhöhen.

Die beste Personio Integration ist meist kleiner als das erste Architekturdiagramm. Eine schmale, beobachtbare Übergabe mit klarer Datenhoheit ist verlässlicher als ein breiter bidirektionaler Sync, dessen Konfliktregeln niemand eindeutig erklären kann.

Häufige Fragen zur Personio API

Hat Personio eine offene API?

Personio stellt dokumentierte Public APIs und Webhooks bereit. Der Zugriff hängt jedoch von Paket, aktivierten Produkten, Credential-Scopes und freigegebenen Attributen ab. „Public“ bedeutet nicht, dass sich jede Oberfläche oder jeder Workflow von außen steuern lässt.

Kann die Personio API Bewerbungen anlegen?

Ja. Die Recruiting API kann für einen geeigneten veröffentlichten Job eine Bewerbung erstellen und zuvor hochgeladene Dokumente anhängen. Der Aufruf gehört ins Backend. Planen Sie Validierungsfehler, Duplikate und das spezifische Rate Limit ein.

Kann ich alle Kandidatenfelder und Tags auslesen?

Nein. Die aktuellen v2-Leseendpunkte für Kandidaten und Bewerbungen liefern laut Dokumentation keine Custom Attributes und Tags. Prüfen Sie die für Ihr Screening oder Reporting benötigten Felder, bevor Sie die technische Lösung festlegen.

Ist die Personio DATEV Schnittstelle dasselbe wie die Public API?

Nein. Sie ist eine eigene Lohnabrechnungsintegration mit DATEV-spezifischer Autorisierung, Datenservices, Attributen und Dokumentenwegen. Nutzen Sie diese Verbindung für den unterstützten Abrechnungsprozess. Ergänzen Sie individuelle Validierung nur für einen klar getrennten Bedarf.

Sollten wir eine Personio Integration selbst entwickeln?

Entwickeln Sie selbst, wenn der Ablauf unterscheidend ist, alle nötigen API-Operationen existieren und Ihr Team den Connector dauerhaft betreiben kann. Wählen Sie ein Modul, wenn Workflow, Oberfläche, Monitoring und Wartung schwieriger sind als der reine Datentransfer.