HR-Software-API und Exit-Strategie: Datenhoheit von Anfang an sichern
Wer heute eine neue HR-Software für Payroll, Personalakte, Recruiting oder Talent Management einführt, unterschreibt in aller Regel einen Vertrag für drei bis fünf Jahre und denkt dabei fast nie an den Tag, an dem dieser Vertrag wieder endet. Genau das ist der teuerste Fehler bei der HR-Software-Auswahl in Deutschland: Die Exit-Strategie wird erst verhandelt, wenn der Wechsel bereits unausweichlich ist, und damit aus einer Position der Schwäche heraus.
Nach dem Cloud-Report 2025 von Bitkom Research (Befragung in KW 12 bis 19/2025, 604 Unternehmen ab 20 Beschäftigten) fühlen sich 53 Prozent der cloud-nutzenden Unternehmen in Deutschland ihren Cloud-Anbietern bei Preisen und Vertragskonditionen „ausgeliefert". Gleichzeitig stufen bislang nur 41 Prozent der Unternehmen eine einfache Wechselmöglichkeit überhaupt als zwingendes Auswahlkriterium ein. Verschärft wird die Lage durch den EU Data Act (Verordnung (EU) 2023/2854), dessen Kapitel zu Cloud-Wechsel und Datenportabilität seit dem 12. September 2025 gilt und HR-Software als Software-as-a-Service explizit mit erfasst.
Warum eine Exit-Strategie zur Auswahl gehört, nicht erst zur Kündigung
Datenhoheit wird in den meisten Ausschreibungen erst zum Thema, wenn es bereits zu spät ist.
Drei Situationen, in denen Vendor-Lock-in teuer wird
In den meisten HR-Software-Ausschreibungen dominieren Funktionsumfang, User Experience und Preis pro Kopf die Entscheidung. API-Dokumentation, Exportformate und Exit-Konditionen tauchen, wenn überhaupt, als Fußnote im Pflichtenheft auf.
- Beim Anbieterwechsel: „offene API" erlaubt oft nur Lesezugriff auf Teildaten
- Bei Carve-outs: Beim Betriebsübergang nach § 613a BGB sind die Beschäftigten vorab zu unterrichten, und die Daten des übergehenden Bereichs müssen sich sauber trennen und exportieren lassen
- Bei regulatorischem Zwang: kurzfristiger Exportweg statt 90-Tage-Kündigungsfrist nötig
Exit-by-Design als fester Bestandteil der Auswahl
Eine belastbare Exit-Strategie beginnt nicht mit der Kündigung, sondern mit dem Lastenheft. API-Vollständigkeit wird als eigenständiges, gewichtetes Bewertungskriterium geprüft, nicht als Nebensatz im Anbietergespräch.
- Exportformate werden vor Unterschrift per Testmigration verifiziert
- Data-Ownership-Klauseln stehen explizit im Vertrag, nicht in den AGB
- Exit-Fähigkeit wird über die Laufzeit regelmäßig erneut getestet
Verhandlungsposition vor Vertragsunterschrift nutzen
Diese Denkweise kostet in der Einführungsphase zusätzliche Zeit und verhandlungstechnisches Kapital. Sie zahlt sich aber genau dann aus, wenn ein Wechsel unausweichlich wird: durch Übernahme, Repricing oder ein besseres System am Markt. Wie sich ein solcher Wechsel planen lässt, beschreibt HR-Software wechseln und Daten migrieren.
- Mindestens die Dimensionen API, Vertrag und Übergangsfrist vertraglich zusichern lassen
- Mündliche Zusagen im Vertrieb ersetzen keinen technischen Test
- Mehr dazu in unserer HR-Systemarchitektur
Die Exit-Readiness-Bewertungsmatrix für HR-Software
Statt eines Anbietervergleichs, der bei einem Architektur- und Methodikthema wenig aussagekräftig wäre, braucht es ein Bewertungsraster, mit dem Fachbereich, IT und Einkauf jede HR-Software anhand derselben fünf Dimensionen und drei Reifegrade einstufen können.
| Dimension | Basis (Restrisiko hoch) | Fortgeschritten (Marktüblich) | Best Practice (Zielbild) |
|---|---|---|---|
API-VollständigkeitZugriff auf Entitäten |
Nur Lesezugriff auf Stammdaten; Bewegungsdaten, Dokumente und Freitextfelder gesperrt | Lese-/Schreibzugriff auf die meisten Objekte via REST/OData, aber mit Rate-Limits; Bulk-API oft nur im höheren Preistier | Vollständiger, dokumentierter Zugriff inkl. Anhängen, Audit-Trails, Bulk-Endpunkt, SCIM-Unterstützung, ohne Aufpreis im Standardvertrag |
ExportformateDatenstandards |
Ausschließlich proprietäre CSV-Exporte ohne Datenmodell oder Feldbeschreibung | Strukturierte JSON-/XML-Exporte mit rudimentärer Dokumentation der Feldsemantik | Maschinenlesbare Exporte orientiert an offenen Schemata (z. B. HR Open Standards Consortium) mit vollständigen Metadaten und referenzieller Integrität |
Vertragliche KlauselnData Ownership |
Vertrag verweist pauschal auf AGB; keine Aussage zu Eigentum, Export oder Löschung | Kündigungsfrist und allgemeiner Rückgabeanspruch, aber ohne Format, Frist oder Kostenregelung | Eigene Data-Ownership-Klausel mit Exportfrist, Format, Kostenobergrenze; bei kritischen Systemen ergänzt um Data-Escrow |
ÜbergangsfristenAnbieter-Mitwirkung |
Zugriff endet zum Vertragsende ohne Frist; Löschung oft kurzfristig und nicht fixiert | Fixierte Übergangsfrist von einigen Wochen mit Lesezugriff, aber ohne aktive Migrationsunterstützung | Mind. 30 Kalendertage mit aktiver Mitwirkungspflicht (Ansprechperson, Support, Exportwerkzeuge), orientiert am EU Data Act |
TestbarkeitSandbox |
Kein Testzugang vor Vertragsabschluss; API-Verhalten erst nach Unterschrift sichtbar | Demo-/Trial-Zugang vorhanden, aber ohne repräsentative Datenmenge oder Exportsimulation | Dedizierte Sandbox mit synthetischen, strukturell realistischen Testdaten für vollständige Testmigration vor Unterschrift |
Nach unserer Einschätzung sollte kein Fachbereich einen mehrjährigen HR-Software-Vertrag unterschreiben, ohne mindestens die Dimensionen API-Vollständigkeit, Vertragsklauseln und Übergangsfristen im „Fortgeschritten"-Niveau vertraglich zugesichert zu bekommen. Eine detaillierte Prüf-Checkliste bietet unsere HR-Software-Checkliste.
Sieben Aspekte, die im Detail entscheiden
Eine „offene API" ist ein Marketingbegriff, kein technisches Kriterium. Diese Aspekte sollten vor jeder Vertragsunterschrift konkret geprüft werden.
API-Vollständigkeit richtig prüfen
Entscheidend ist, ob eine echte Entity-API vorliegt oder nur „Report as a Service", und ob Bulk-/Async-Muster sowie Cursor-Pagination für Vollexporte bei großen Belegschaften unterstützt werden. Die technischen Prüfpunkte zu Schnittstellenstilen, Webhooks, Fehlerformaten und Limits stehen in den folgenden Abschnitten dieser Seite.
Zugriffsvoraussetzungen klären
Authentifizierungsverfahren (marktüblich OAuth2 Client-Credentials), Scopes für Bulk-Lesezugriffe, IP-Allowlisting und Rotationspflichten für API-Keys entscheiden, ob ein Export im Ernstfall praktisch durchführbar ist, nicht erst das Datenmodell.
Exportformate: strukturiert statt proprietär
Art. 20 DSGVO verlangt, soweit anwendbar, ein „strukturiertes, gängiges und maschinenlesbares Format". Ohne Datenwörterbuch wird selbst ein technisch sauberer Export im Zielsystem zur Blackbox.
Vendor-Lock-in systematisch erfassen
Lock-in entsteht nicht nur durch fehlende APIs, sondern auch prozessual: individuelle Freigabe-Workflows, unternehmensspezifische Reportings oder Schnittstellen zu Payroll-Dienstleistern wie DATEV, die im neuen System nachgebaut werden müssen.
Data-Ownership vertraglich verankern
Ohne explizite Regelung greift ersatzweise § 675 BGB mit Verweis auf den Herausgabeanspruch nach § 667 BGB, der im Streitfall deutlich schwerer durchzusetzen ist als eine klare Exit-Klausel im Vertrag selbst.
Übergangsfristen realistisch bemessen
Der EU Data Act setzt ein zweistufiges Fristenmodell: erst eine Mitteilungsfrist von max. zwei Monaten, danach eine technische Übergangsfrist von i. d. R. 30 Tagen, verlängerbar auf bis zu sieben Monate bei begründeter Komplexität.
Dokumentation und Versionierung der Schnittstellen
APIs ändern sich über eine mehrjährige Vertragslaufzeit. Ohne versionierte, öffentlich einsehbare Dokumentation mit Changelog drohen Breaking Changes, die bestehende Integrationen und geplante Exportroutinen unbemerkt außer Kraft setzen. Best Practice ist eine API mit expliziter Versionsnummer, angekündigter Deprecation-Frist und öffentlich zugänglichem Changelog.
Rechtliche Rahmenbedingungen bei Anbieterwechsel und Datenhoheit
DSGVO, EU Data Act, Aufbewahrungsfristen und Mitbestimmung greifen ineinander. Wer sie erst beim Exit prüft, verliert wertvolle Zeit.
Art. 20: Recht auf Datenübertragbarkeit
Gilt nur für Daten, die auf Einwilligung oder Vertrag beruhen und selbst „bereitgestellt" wurden. Beschäftigtendaten stützen sich überwiegend auf § 26 BDSG. Die Anwendbarkeit auf Personalakten- und Payroll-Daten ist in der Fachliteratur umstritten. Die vertragliche Exit-Klausel darf sich darauf nicht verlassen.
Cloud-Switching-Pflichten seit 09/2025
Verordnung (EU) 2023/2854 verpflichtet Anbieter zu kostenfreien, dokumentierten APIs, einer Übergangsfrist und schrittweiser Abschaffung von Wechselentgelten bis zum vollständigen Verbot am 12. Januar 2027. Aufsicht in Deutschland: Bundesnetzagentur nach dem Data-Act-Durchführungsgesetz (DADG), seit 30. Mai 2026 in Kraft (Quelle: Haufe, Stand: Oktober 2026).
Fristen laufen nach Vertragsende weiter
Lohnkonten sechs Jahre (§ 41 EStG), Buchungsbelege acht Jahre (§ 147 AO). Für bAV-Unterlagen empfiehlt sich bis zu 30 Jahre Aufbewahrung, da Ansprüche nach § 18a BetrAVG erst dann verjähren. Ohne Nachweis sind sie sonst nicht belegbar.
Auftragsverarbeitung
Der AVV sollte explizit regeln, was bei Beendigung der Verarbeitung geschieht: Rückgabe oder Löschung, Format, Frist. Fehlt dies, fallen datenschutzrechtlicher und zivilrechtlicher Rahmen im Exit-Fall auseinander.
§ 87 Abs. 1 Nr. 6 BetrVG
Ein Systemwechsel berührt in der Regel Mitbestimmungsrechte, da HR-Systeme Verhaltens- oder Leistungsüberwachung ermöglichen können. Ohne rechtzeitige Abstimmung mit dem Betriebsrat verzögert sich der gesamte Migrationszeitplan.
Haftung bei Datenverlust
Datenmigrationsprojekte überschreiten häufig Budget oder Zeitrahmen, wenn Datenmodell und Exportformat vorab nicht getestet wurden. Bei HR-Daten ist Datenverlust nicht nur ein IT-, sondern ein arbeits- und aufsichtsrechtliches Risiko.
In sechs Schritten zur belastbaren Exit-Strategie
Von der Aufnahme ins Lastenheft bis zum strukturiert durchgeführten Wechsel im Bedarfsfall.
Exit-Kriterien ins Lastenheft aufnehmen
API-Vollständigkeit, Exportformate und Data-Ownership werden als eigenständige, gewichtete Kriterien definiert, mit denselben Punktzahlen wie Kernfunktionen.
API-Audit im Auswahlprozess
Öffentliche API-Dokumentation prüfen und, wo möglich, Testzugang nutzen: Entitäten, Rate-Limits, Bulk-/Async-Muster, Authentifizierung und Aktualität der Dokumentation.
Exit-Klauseln fixieren
Data-Ownership, Exportformat, Übergangsfrist, Mitwirkungspflichten und Kostenobergrenze werden als eigene Vertragsanlage verhandelt, nicht dem AGB-Text überlassen.
Testmigration vor Go-Live
Vollständiger Exportlauf mit repräsentativen (ggf. anonymisierten) Testdaten, überführt ins Zielformat, um zugesicherte Exportfähigkeit tatsächlich zu verifizieren.
Exit-Fähigkeit regelmäßig prüfen
Die Exit-Readiness-Matrix wird in festem Turnus, jährlich oder bei größeren Releases, erneut durchlaufen, da sich API-Umfang und Recht ändern können.
Exit strukturiert durchführen
Kündigung, Aktivierung der Übergangsfrist, vollständiger Export, Betriebsrats-Abstimmung und Verifikation aller aufbewahrungspflichtigen Daten vor Zugriffsende.
Häufig gestellte Fragen
Antworten auf die wichtigsten Fragen zu API-Vollständigkeit, Exportformaten und Datenhoheit bei HR-Software.
Was bedeutet Datenhoheit bei HR-Software konkret?
Datenhoheit bedeutet, dass ein Unternehmen jederzeit die faktische und rechtliche Kontrolle über seine im HR-System gespeicherten Daten behält, unabhängig davon, bei welchem Anbieter die Daten technisch gehostet werden. Das umfasst das Recht auf vollständigen, unbeschränkten Export in einem nutzbaren Format, die Gewissheit, dass keine versteckten technischen oder vertraglichen Hürden den Zugriff einschränken, sowie die Klarheit, wem die Daten rechtlich zugeordnet sind. In der Praxis zeigt sich Datenhoheit weniger an Marketingaussagen des Anbieters als an konkreten Vertragsklauseln und tatsächlich getesteten Exportwegen.
Welche Daten muss ein HR-Software-Anbieter beim Wechsel herausgeben?
Grundsätzlich alle Daten, die das Unternehmen eingegeben oder die im System für das Unternehmen generiert wurden: Stammdaten, Bewegungsdaten, Dokumentenanhänge, Genehmigungs- und Änderungshistorien sowie, je nach vertraglicher Vereinbarung, auch Konfigurationsdaten wie Workflow-Regeln. Der genaue Umfang hängt vom Vertrag ab; ohne explizite Data-Ownership-Klausel besteht das Risiko, dass sich der Anbieter auf einen eingeschränkten „Standardexport" beschränkt. Für personenbezogene Daten greift ergänzend das Recht auf Datenübertragbarkeit nach Art. 20 DSGVO, dessen Anwendbarkeit auf klassische Personalakten- und Payroll-Daten aber rechtlich nicht unumstritten ist, weil diese meist auf § 26 BDSG statt auf Vertrag oder Einwilligung gestützt werden. Verlässlicher als das gesetzliche Individualrecht ist deshalb eine eigene, unternehmensweite Vertragsklausel.
Gilt der EU Data Act auch für HR-Software als SaaS-Lösung?
Ja. Der EU Data Act (Verordnung (EU) 2023/2854) definiert „Datenverarbeitungsdienste" breit und erfasst damit ausdrücklich auch Software-as-a-Service-Angebote wie Cloud-basierte HR-Software, nicht nur reine Infrastrukturdienste (IaaS). Die Cloud-Switching-Vorschriften in Kapitel VI der Verordnung gelten seit dem 12. September 2025 und damit auch für bereits bestehende Verträge. Allerdings garantiert der Data Act primär technische Datenportabilität und offene Schnittstellen, nicht aber inhaltliche Funktionsgleichheit zwischen Alt- und Neusystem.
Wie lange dauert ein Anbieterwechsel bei HR-Software laut Data Act?
Der EU Data Act sieht ein zweistufiges Fristenmodell vor: zunächst eine Mitteilungsfrist von maximal zwei Monaten, in der der Kunde den Wechsel gegenüber dem Anbieter ankündigt, danach eine technische Übergangsfrist von im Regelfall 30 Kalendertagen für die eigentliche Datenübertragung. Kann der Anbieter innerhalb von 14 Werktagen technisch begründen, dass dieser Zeitrahmen bei komplexen Systemen nicht ausreicht, kann sich die Übergangsfrist auf bis zu sieben Monate verlängern. Zusätzlich hat der Kunde nach Ablauf der Übergangsfrist noch mindestens 30 weitere Kalendertage Zeit, um Daten abzurufen, bevor der Anbieter sie löschen darf.
Was kostet der Datenexport beim Anbieterwechsel?
Nach dem EU Data Act dürfen Anbieter im Zeitraum vom 11. Januar 2024 bis zum 12. Januar 2027 nur noch „direkte, kostenbezogene" Wechselentgelte verlangen (Quelle: Art. 29 Verordnung (EU) 2023/2854, Stand: Oktober 2026). Pauschale Straf- oder Abschreckungsgebühren sind bereits jetzt unzulässig. Ab dem 12. Januar 2027 entfallen Switching-Fees vollständig. Bis dahin sollten Unternehmen die konkrete Kostenstruktur für Exportunterstützung vor Vertragsunterschrift verhandeln, statt sich erst im Kündigungsfall mit den Preisen des Anbieters auseinanderzusetzen.
Welche Exportformate sollte eine HR-Software mindestens unterstützen?
Mindeststandard sind strukturierte, dokumentierte Formate wie CSV mit begleitendem Datenwörterbuch oder JSON/XML mit klar definiertem Schema. Reine PDF-Ausdrucke oder proprietäre Binärformate ohne Dokumentation gelten nicht als ausreichend im Sinne von Art. 20 DSGVO. Best Practice orientiert sich, wo verfügbar, an offenen, herstellerneutralen Schemata wie denen des HR Open Standards Consortium; in der Breite des deutschen Marktes ist die native Unterstützung solcher Schemata für Kern-HR-Daten aber noch die Ausnahme, weshalb ein sauberes eigenes Datenwörterbuch häufig der realistischere Maßstab ist. Für Identitäts- und Zugriffsdaten hat sich zusätzlich der SCIM-Standard etabliert.
Was passiert mit Gehaltsabrechnungen und Personalakten nach Vertragsende?
Gesetzliche Aufbewahrungspflichten bestehen unabhängig vom Softwarewechsel fort: Lohnkonten sind nach § 41 EStG sechs Jahre und steuerlich relevante Belege nach § 147 AO seit 2025 acht Jahre aufzubewahren. Für Unterlagen zur betrieblichen Altersvorsorge gibt es keine eigene gesetzliche Aufbewahrungsfrist; in der Praxis werden sie dennoch bis zu 30 Jahre vorgehalten, weil Leistungsansprüche nach § 18a BetrAVG erst nach 30 Jahren verjähren und ohne Nachweisunterlagen sonst nicht mehr belegbar sind. Diese Daten müssen entweder im neuen System oder in einem separaten, GoBD-konformen Archivsystem revisionssicher vorgehalten werden.
Muss der Betriebsrat bei einem Wechsel der HR-Software beteiligt werden?
In den meisten Fällen ja: HR-Software, die Verhaltens- oder Leistungsdaten von Beschäftigten erfasst oder auswerten kann, fällt unter das Mitbestimmungsrecht nach § 87 Abs. 1 Nr. 6 BetrVG. Ein Systemwechsel, auch wenn er primär als IT- oder Migrationsprojekt verstanden wird, sollte daher frühzeitig mit dem Betriebsrat abgestimmt werden, um Verzögerungen im Migrationszeitplan zu vermeiden. Die konkrete Ausgestaltung hängt vom Funktionsumfang des neuen Systems ab und sollte im Zweifel arbeitsrechtlich geprüft werden.
Wie teste ich die Exit-Fähigkeit eines HR-Software-Anbieters vor Vertragsunterschrift?
Der zuverlässigste Weg ist eine Testmigration mit repräsentativen, idealerweise anonymisierten Testdaten in einer Sandbox-Umgebung: Ein vollständiger Exportlauf über die angebotene API wird durchgeführt und geprüft, ob alle im Lastenheft geforderten Datenobjekte, Anhänge und Beziehungen tatsächlich abrufbar sind, inklusive eines Blicks auf Authentifizierungsverfahren und die Geschwindigkeit, mit der neue API-Zugänge im Bedarfsfall bereitgestellt werden. Eine mündliche Zusage im Vertriebsgespräch ersetzt diesen technischen Test nicht.
Was tun, wenn ein bestehender Vertrag keine Exit-Klausel enthält?
Auch ohne explizite Exit-Klausel bestehen gesetzliche Mindestrechte: das Recht auf Datenübertragbarkeit nach Art. 20 DSGVO für personenbezogene Daten, wobei seine Anwendbarkeit auf Beschäftigtendaten rechtlich diskutiert wird, sowie seit September 2025 die Cloud-Switching-Pflichten des EU Data Act, sofern der Anbieter als Datenverarbeitungsdienst im Sinne der Verordnung gilt. Unternehmen sollten in diesem Fall frühzeitig, spätestens mit der nächsten ordentlichen Kündigungsfrist, schriftlich auf diese gesetzlichen Ansprüche verweisen und eine Nachverhandlung der Exit-Konditionen anstoßen, statt bis zum Vertragsende zu warten.
Welche Authentifizierung sollte die API einer HR-Software unterstützen?
Marktüblich ist OAuth 2.0, für Exporte und Integrationen meist per Client Credentials, ergänzt um OpenID Connect oder SAML 2.0 für Single Sign-on. Für die Provisionierung von Benutzerkonten ist SCIM 2.0 der übliche Standard. Prüfen Sie im Test Scopes, Token-Lebensdauer, Rotation von Secrets und die Frage, wie schnell neue API-Zugänge bereitgestellt werden. Aussagen des Anbieters gelten bis zum Nachweis als Herstellerangabe.
Wie werden Webhooks sicher und zuverlässig betrieben?
Der Empfänger prüft die Signatur jedes Ereignisses, bestätigt mit einem 2xx-Status erst nach erfolgreicher Verarbeitung und erkennt doppelte Zustellungen an einer Ereignis-ID. Fehlgeschlagene Ereignisse landen in einer Dead-Letter-Queue. Secrets werden regelmäßig rotiert. Fragen Sie den Anbieter nach Wiederholungsregeln, Zustellgarantie und Versionierung der Ereignisformate.
Was ändert der Digital Omnibus am Data Act für HR-Software?
Nach unserem Stand vom Oktober 2026 liegt für Kapitel VI des Data Act ein Änderungsvorschlag vor, der enge Übergangsausnahmen für Altverträge vor dem 12. September 2025 vorsieht, etwa für kundenspezifisch angepasste Standarddienste und für kleine und mittlere Anbieter. Das Verbot von Wechselentgelten ab dem 12. Januar 2027 bleibt dabei bestehen. Das Verfahren war nach der Quelle von Juli 2026 noch nicht abgeschlossen, prüfen Sie daher den aktuellen Stand und lassen Sie die Vertragslage juristisch bewerten.
Welche Kennzahlen zeigen, ob eine HR-Integration gesund ist?
Aussagekräftig sind Datenfrische je Objekt, Fehlerraten je Endpunkt, Wiederholungsquote und Rückstau, Abweichungen zwischen aktiven Konten und aktiven Beschäftigungen sowie Sicherheitssignale wie abgelehnte Signaturen. Ergänzend helfen Prozesszeiten, etwa die Dauer von Eintritt bis Kontenbereitstellung. Die Schwellenwerte legen Sie im Projekt selbst fest und dokumentieren sie je Datenfluss.
Schnittstellenstile, Authentifizierung und Provisionierung
Ob ein Export im Ernstfall funktioniert, hängt an der Schnittstelle. Vier Fragen klären den Kern: Welcher Stil, welche Anmeldung, welche Rollen, welche Provisionierung.
Im HR-Umfeld dominieren REST-Schnittstellen, weil System-zu-System-Anbindungen stabil und gut testbar sein müssen. Beschreibt ein Anbieter seine API mit OpenAPI, lassen sich Endpunkte, Datentypen, Authentifizierung und Fehler maschinenlesbar prüfen, etwa für Mock-Server, Contract-Tests und Client-Generierung. Für Vollexporte und Integrationen ist das ein belastbarer Nachweis, für UI-nahe Szenarien kann GraphQL sinnvoll sein.
| Stil | Stärke | Worauf bei Exit und Export zu achten ist |
|---|---|---|
| REST mit OpenAPI | Hohe Werkzeugreife, klarer Lebenszyklus, gut für ETL und iPaaS | Vollständigkeit der Entitäten, Paginierung per Cursor, Bulk- oder Async-Endpunkt für große Belegschaften |
| GraphQL | Clients fragen genau die benötigten Felder ab, praktisch bei verschachtelten Objekten wie Person, Beschäftigung und Vergütung | Berechtigungen je Feld, Abfragekomplexität und Caching, Vollexport nur mit klar definierten Abfragen |
| Events und Webhooks | Statusänderungen werden gepusht, nützlich für Provisionierung und Audit | Kein Ersatz für einen Vollexport, Zustellgarantie und Wiederholung prüfen |
Für die Autorisierung von API-Zugriffen hat sich OAuth 2.0 etabliert (RFC 6749): Client Credentials für Maschine-zu-Maschine-Zugriffe, Authorization Code für Benutzerflüsse. OpenID Connect ergänzt OAuth 2.0 um die Identität der Anwender und ist die Grundlage für Single Sign-on, alternativ wird SAML 2.0 eingesetzt. Zugriffstoken liegen häufig als JSON Web Token vor (RFC 7519), signiert und kurzlebig. Für die automatische Anlage, Änderung und Deaktivierung von Benutzerkonten ist SCIM 2.0 der übliche Standard (RFC 7643 und RFC 7644).
Scopes und Least Privilege
Eine Export-Integration sollte nur die Felder lesen dürfen, die sie braucht. Prüfen Sie, ob getrennte Lese- und Schreib-Scopes möglich sind.
Token-Lebensdauer und Rotation
Kurzlebige Token, Refresh und die Rotation von Client-Secrets entscheiden, ob ein Export auch Monate nach der Einrichtung noch läuft.
Provisionierung und De-Provisionierung
Wird der Austritt in HR automatisch an Zielsysteme weitergegeben, sinkt das Risiko verwaister Konten. Prüfen Sie SCIM-Endpunkte im Test.
Quellen: OpenAPI Specification 3.1.1, RFC 6749 (OAuth 2.0), RFC 7644 (SCIM-Protokoll), RFC 7519 (JWT). Stand: Oktober 2026.
Ereignisgesteuerte HR-Prozesse verlässlich betreiben
Webhooks halten Systeme synchron, ohne ständiges Abfragen. Sie sind nur dann verlässlich, wenn Sender und Empfänger bestimmte Regeln einhalten.
Typische Ereignisse sind Neuanlage und Änderung einer Beschäftigung oder die Genehmigung einer Abwesenheit. Ob ein Anbieter Signatur, Wiederholung und Versionierung der Ereignisse unterstützt, ist vor der Unterschrift zu klären und im Test zu belegen (Herstellerangabe, bis der Nachweis vorliegt).
Signatur prüfen
Eingehende Ereignisse werden anhand einer Signatur, häufig HMAC, verifiziert. Secrets werden rotiert und nie im Quelltext abgelegt.
Nur bei Erfolg bestätigen
Der Empfänger antwortet mit einem 2xx-Status erst, wenn die Verarbeitung gelungen ist. Andernfalls stellt der Anbieter erneut zu.
Doppelte Zustellung einplanen
Ein Ereignis kann mehrfach eintreffen. Eine eindeutige Ereignis-ID erlaubt die Deduplizierung, die Verarbeitung bleibt idempotent.
Fehlerfälle auffangen
Eine Outbox oder Dead-Letter-Queue hält fehlgeschlagene Ereignisse zur Nachverarbeitung bereit, statt sie zu verlieren.
Ereignisse versionieren
Ändert sich das Ereignisformat, braucht der Empfänger eine Ankündigungsfrist und eine Versionskennung.
Ausnahmen mit Mensch
Bei sensiblen Vorgängen wie Austritt oder Gehaltsänderung kann eine manuelle Freigabe vorgeschaltet werden.
Versionierung, Fehlerformate, Limits und Idempotenz
Gute Schnittstellen sind vorhersehbar. Genau das lässt sich vor Vertragsabschluss mit wenigen Fragen und einem Testlauf prüfen.
| Merkmal | Was es leistet | Prüffrage an den Anbieter |
|---|---|---|
| Versionierung | Breaking Changes erscheinen in einer neuen Version, etwa im Pfad (/v1/) oder per Header | Gibt es eine Ankündigungsfrist für Abkündigungen und ein öffentliches Changelog? |
| Fehlerformat | Strukturierte, maschinenlesbare Fehler nach „Problem Details“ (RFC 9457, application/problem+json) | Liefern Fehlerantworten Typ, Titel, Status und Detail? |
| Rate-Limits | HTTP 429 (RFC 6585) mit Retry-After (RFC 9110), Clients drosseln mit Backoff | Wie hoch sind die Limits für einen Vollexport, und gelten sie je Client oder je Mandant? |
| Idempotenz | Wiederholte Schreibaufrufe erzeugen keine Duplikate, üblich ist ein Idempotency-Key | Wird ein Idempotency-Key unterstützt? Der zugehörige IETF-Entwurf ist nach unserem Stand noch kein RFC. |
| Gleichzeitige Änderungen | ETag und If-Match (RFC 9110) verhindern, dass parallele Updates sich überschreiben | Sind Schreibzugriffe mit ETag abgesichert? |
| Paginierung | Cursor statt Offset sichert Vollständigkeit bei Änderungen während des Exports | Wie wird ein Vollexport bei 10.000 Beschäftigten paginiert? |
Rate-Limits sind beim Exit der häufigste praktische Engpass. Ein Limit, das für den Tagesbetrieb reicht, kann einen Vollexport über Tage strecken. Rechnen Sie im Test mit, wie lange der Export Ihrer Beschäftigtenzahl bei dem vertraglich zugesicherten Limit dauert, und vergleichen Sie das Ergebnis mit der geplanten Übergangsfrist.
Quellen: RFC 9457 (Problem Details), RFC 6585 (Status 429), RFC 9110 (HTTP Semantics), IETF-Entwurf Idempotency-Key. Stand: Oktober 2026.
Der Testlauf: Was ein Vollexport belegen muss
Ein Vollexport in der Sandbox ist der härteste Nachweis. Er zeigt Umfang, Dauer und Qualität der Daten, bevor ein Vertrag gilt.
| Datenobjekt | Prüfung im Testlauf | Typische Lücke |
|---|---|---|
| Stammdaten Person und Beschäftigung | Alle Felder inklusive Historie und Gültigkeitszeiträumen abrufbar | Nur der aktuelle Stand, keine Historie |
| Vergütung und Abrechnungsdaten | Bestandteile, Änderungen und Rückmeldungen aus der Abrechnung | Nur Ergebnisse, keine Eingangsdaten |
| Abwesenheiten und Zeitdaten | Anträge, Genehmigungen, Salden und Korrekturen | Salden ohne Buchungshistorie |
| Dokumente und Anhänge | Dateien mit Metadaten und Zuordnung zur Person | Dokumente nur über die Oberfläche herunterladbar |
| Audit-Trail und Änderungshistorie | Wer hat wann was geändert | Protokoll nur als Bericht, nicht per API |
| Konfiguration | Workflow-Regeln, Rollen, Feldlisten, Wertelisten | Konfiguration nicht exportierbar, Neuaufbau nötig |
Rechenbeispiel von Find-Your-HR mit eigenen Annahmen: Bei 10.000 Beschäftigten und durchschnittlich 40 Datensätzen je Person (Stammdaten, Beschäftigungen, Vergütungen, Abwesenheiten) ergeben sich 400.000 Datensätze. Bei 100 Datensätzen je Seite sind das 4.000 Aufrufe. Erlaubt der Vertrag 60 Aufrufe pro Minute, dauert der Lauf rund 67 Minuten, bei 10 Aufrufen pro Minute rund 400 Minuten, also gut 6 Stunden. Dokumente und Anhänge kommen hinzu. Die Rechnung zeigt, warum Limits und Bulk-Endpunkte in die Vertragsanlage gehören.
Welche Entitäten sind per API lesbar?
Bitten Sie um eine Liste aller Objekte, getrennt nach lesbar, schreibbar und nur über die Oberfläche verfügbar.
Gelten für Exporte eigene Limits?
Klären Sie, ob Bulk-Endpunkte im Standardvertrag enthalten sind oder nur in höheren Preisstufen.
Gibt es ein Datenwörterbuch?
Ohne Feldbeschreibung ist ein Export im Zielsystem schwer zu deuten.
Wie lange bleibt der Zugriff nach Vertragsende?
Fordern Sie eine feste Frist mit Lesezugriff und benannter Ansprechperson.
Was kostet Exportunterstützung?
Verhandeln Sie eine Obergrenze oder einen Stundensatz vorab, Preise auf Anfrage sind schriftlich festzuhalten.
Wann wurde die Exportfunktion zuletzt getestet?
Ein Nachweis aus einem aktuellen Release ist belastbarer als eine allgemeine Zusage.
Was in die API-Anlage des Vertrags gehört
Technische Zusagen ohne Vertragsbezug lassen sich im Streitfall kaum durchsetzen. Eine eigene Anlage macht sie prüfbar.
Die Anlage ergänzt die Exit-Klausel und die Auftragsverarbeitung nach Art. 28 DSGVO. Sie sollte nur Punkte enthalten, die messbar sind, und verweist für Details auf die aktuelle öffentliche Dokumentation. Lassen Sie den Entwurf von Rechtsabteilung und, wo erforderlich, Betriebsrat prüfen, Hinweise dazu gibt die Seite zum Betriebsrat im HR-Projekt.
Umfang der API
Liste der per API zugänglichen Objekte und Zusage, dass der Umfang bei Updates nicht schrumpft.
Verfügbarkeit und Support
Verfügbarkeitsziel der Schnittstelle, Reaktionszeiten bei Störungen und benannte technische Ansprechperson.
Änderungen und Abkündigung
Ankündigungsfrist für Breaking Changes, parallele Laufzeit alter Versionen, öffentliches Changelog.
Limits und Bulk-Zugriff
Vertraglich zugesicherte Limits, Bulk-Endpunkt im Standardumfang, keine Drosselung während der Übergangsfrist.
Sandbox und Testdaten
Dauerhafter Testzugang mit synthetischen Daten, auch nach Go-Live, um Exportroutinen regelmäßig zu prüfen.
Kosten
Enthaltene Leistungen, Preise für zusätzliche Exportunterstützung und eine Obergrenze für Wechselentgelte.
Ein Beispiel für die Praxis: Wird der Export jährlich in der Sandbox wiederholt, zeigt sich eine verengte API früh und nicht erst bei der Kündigung. Der Aufwand liegt bei wenigen Stunden, die Dokumentation des Ergebnisses dient als Nachweis gegenüber Revision und Geschäftsleitung. Einzelne Anbieter legen ihre API-Dokumentation öffentlich offen, andere erst nach Vertragsabschluss, prüfen Sie deshalb früh, was einsehbar ist. Die Anbieterübersicht finden Sie unter HR-Software-Anbieter.
Datenflüsse, Verträge und Muster
Ein stabiles Datenmodell erleichtert Integration und Exit gleichermaßen. Es lässt sich mit einfachen Mitteln absichern.
Definieren Sie Kernobjekte wie Person, Beschäftigung, Organisation, Abwesenheit und Vergütung mit Pflichtfeldern, Formaten und erlaubten Werten. Mit OpenAPI und dem zugrunde liegenden JSON-Schema lassen sich diese Regeln maschinenlesbar beschreiben. Wer die Schemas in einem Versionsverwaltungssystem hält und bei jeder Änderung automatisch gegen Beispieldaten validiert, erkennt Abweichungen vor dem Betrieb. Consumer-Driven Contracts, bei denen der Empfänger seine Erwartungen als Test hinterlegt, ergänzen das.
| Datenfluss | Typische Kontrollen | Hinweis |
|---|---|---|
| Hire to Pay (Stammdaten an Payroll) | Pflichtfelder für Steuer und Sozialversicherung, Änderungen mit Gültigkeitsdatum, Rückmeldung von Fehlern | Parallellauf zur Abnahme, Delta-Exporte je Ereignis plus monatlicher Vollabgleich. Siehe Payroll-Software |
| Identität und Zugriff (HR, Identity-Provider, Zielsysteme) | SSO per SAML oder OIDC, Provisionierung per SCIM | HR bleibt führend für den Beschäftigungsstatus, Rollen werden aus Organisation und Stelle abgeleitet |
| Analytics und Data Warehouse | Bulk-Export plus inkrementelle Abzüge, Pseudonymisierung, Rollenfilter | Datenkatalog und Herkunft dokumentieren. Datenschutz siehe DSGVO und HR-Software |
| Service-Flows (Tickets, Onboarding) | Webhook-Signatur, Idempotenz, Dead-Letter-Queue | Eintritt löst Aufgaben für IT, Zutritt und Willkommenspaket aus |
Punkt zu Punkt
Einfacher Start und geringe Latenz. Bei wachsender Zahl an Systemen entsteht ein schwer wartbares Geflecht.
iPaaS und Orchestrierung
Schnelle Zuordnung von Feldern und zentrales Monitoring. Prüfen Sie Abhängigkeit vom Plattformanbieter und den Umgang mit sensiblen Zugangsdaten.
Event-Hub
Entkoppelt Sender und Empfänger und skaliert. Erfordert ein Schema-Register und ein Konzept zur erneuten Verarbeitung.
Monitoring, Kennzahlen und Aufwand der Integration
Eine Schnittstelle, die niemand beobachtet, fällt erst beim Exit auf. Wenige Kennzahlen genügen, um den Zustand dauerhaft zu belegen.
| Kennzahl | Aussage | Beispielhafte Schwelle (eigene Annahme) |
|---|---|---|
| Datenfrische je Objekt | Alter des letzten erfolgreichen Abgleichs | Alarm, wenn Beschäftigtenstammdaten älter als 24 Stunden sind |
| Fehlerrate (4xx und 5xx) | Anteil fehlgeschlagener Aufrufe je Endpunkt und Client | Alarm bei deutlichem Anstieg gegenüber dem Wochenmittel |
| Wiederholungsquote und Rückstau | Wie viele Ereignisse müssen erneut zugestellt werden | Rückstau darf nach einem Lauf nicht wachsen |
| Identitätsabweichung | Aktive Konten ohne aktive Beschäftigung | Null bei Stichtagsabgleich |
| Sicherheitssignale | Abgelehnte Signaturen, Token-Fehler, Limit-Treffer | Jeder Fall wird protokolliert und geprüft |
| Prozesszeiten | Zeit von Eintritt bis Kontenbereitstellung, Abweichungen im Headcount-Bericht | Zielwerte im Projekt festlegen |
Die Schwellen in der Tabelle sind Planungsannahmen von Find-Your-HR und keine Branchenwerte. Legen Sie je Datenfluss ein eigenes Dashboard an und benennen Sie eine verantwortliche Rolle. Beim Aufwand zählen nicht nur Implementierung und Lizenzen, sondern auch Sicherheit, Betrieb und interne Zeit von HR und IT. Als Planungspuffer für Unvorhergesehenes sind 10 bis 20 Prozent gebräuchlich, das ist eine Faustregel ohne belastbare Studie. Die Kostenblöcke zeigt die Seite zum TCO einer HR-Software. Stabilisieren Sie zuerst die kritischen Pfade Payroll und Identität und verfeinern Sie danach Komfort-Flows.
Wie Anforderungen zu Schnittstellen in die Auswahl einfließen, beschreiben die Seiten zur Longlist und zur Bewertung von HR-Software-Demos. Ein Teil der Anbieter dokumentiert seine API öffentlich, andere nur nach Vertragsabschluss. Das ist ein Prüfpunkt, kein Qualitätsurteil.
Exit-Strategie von Anfang an mitdenken, bevor der Vertrag unterschrieben ist
Eine belastbare Exit-Strategie lässt sich nicht nachträglich in einen laufenden HR-Software-Vertrag hineinverhandeln. Sie muss Teil des Auswahlprozesses sein, mit denselben Bewertungskriterien wie Funktionsumfang und Preis. Find-Your-HR unterstützt Unternehmen dabei, API-Vollständigkeit, Exportformate und Data-Ownership-Klauseln systematisch in die HR-Software-Auswahl zu integrieren.