Skip to main content

Liebe Community, 

damit Tools miteinander verbunden werden können - wie z.B. Personio <> MS Teams, Personio <> Culture Amp, Personio <> Azure AD - werden Schnittstellen benötigt. Diese Schnittstellen werden auch APIs genannt.
 

ℹ️  API steht für “Application Programming Interface”.

Bei Personio stellen wir Euch aktuell Mitarbeitendendaten, Anwesenheitsdaten und Abwesenheitsdaten über die API zur Verfügung. Zusätzlich könnt Ihr Recruitingdaten zu Personio übertragen.

Mehr zur API könnt Ihr auch in unserem Developer Hub nachlesen.


Nun wollen wir die API 2.0 für Euch bereitstellen. Wann das genau passiert, kann ich Euch leider noch nicht sagen. Aber was genau kommt, könnt Ihr mitbestimmen! 🤓

Alles was Ihr dafür tun müsst, ist auf folgende Fragen in einem Kommentar unter diesem Post einzugehen - damit landet Ihr auch automatisch im Lostopf für das Apple Watch Gewinnspiel. 

✨ Welche Standards, sollte die API erfüllen?

🎳 Welche Schnittstellen Endpunkte fehlen Euch noch? ​​​​​

📂 Wie kommt Ihr mit unserer Dokumentation im Developer Hub zurecht?


Fragt auch gerne Eure Entwickler*innen & ITler*innen und ladet sie in die Community ein - ich kann mir vorstellen, dass diese auch Input und Ideen mit uns teilen möchten. 

Liebe Grüße
Astrid & das Personio Integrations Team

Es gibt ein paar Ideen zu diesem Thema in unserem Ideation Bereich, daher habe ich einige der Ideen-Autoren hier verlinkt, vielleicht möchtet Ihr an dieser Stelle dazu Feedback geben. :slight_smile: 

@Carmen, @M Meyer, @Wiki, @Sarina Gebhardt, @Kaddyi, @hypmount, @qbq.lm, @denniskr, @lukas.woehrl, @fledeboer, @george, @Jane, @Christian K., @Theresa Nemitz, @Juliageee, @Chipmunkie 


  • Kritisch ist hierbei das Thema Sicherheit / Integrität - bei einem automatisierten Dokumentenaustausch zwischen zwei Systemen ist es von entscheidender Bedeutung, dass das Dokument zuverlässig nur bei dem Mitarbeiter angezeigt werden kann
  • ggfs. zu übergebende Parameter sind
    • ein Dokumententyp zur konkreten Klassifizierung (Vertragsänderung, Belehrung, Abmahnung)
    • eine VOrhaltedauer (bspw. Abmahnung)
    • Status des Dokuments
    • sonstige Einstellparameter zu Dokumenten, auch jene die nur durch die HR-Referenten gesetzt werden können
  •  

 


@Selina vielen Dank für die Verlinkung.

 

@Astrid:

 

Welche Standards, sollte die API erfüllen Welche Schnittstellen Endpunkte fehlen Euch noch? ​​​​ Wie kommt Ihr mit unserer Dokumentation im Developer Hub zurecht?

 

✨Welche Standards bzw. 🎳welche Endpunkte?:

Ein hoher Anteil eurer Kunden nutzt Microsoft 365.

Wann kommen von euch mehr “Out of the Box” Anbindungen? In der Liste der unterstützten Connectors | Microsoft Power Automate vermissen wir auch weiterhin Personio. Dies würde auch ein Schritt für Personio zu einer Einbindung in die gesamte Microsoft Dynamics (ERP) Welt geben.

Man darf ja mal träumen: … stellt euch vor man generiert bei Personio - Settings - API neue Credentials und fügt diese beim Connector auf der MS 365 - Power Automate Seite ein und muss nicht nervig alles von Hand konfigurieren, sondern kann die genannten GET/POST/PATCH/DELETE-Befehle direkt (entsprechend der bei Personio konfigurierten Einstellungen im PowerAutomate feinjustierten Workflow) verwenden.

Aber auch andere API-Integrationen von bereits eingesetzten Lösungen wären sehr hilfreich (bspw. eSign-Lösungen wie DocuWare, AdobeSign in Personio-Workflows integrieren oder Personio in Workflows bei DocuWare/AdobeSign integrieren).

Wie beantwortet Personio klassische CFO/CEO-Fragen bei einem hohen Anteil an leistungsbezogenen Prämien bei Mitarbeitern zur aktuellen Höhe der Personalkosten? - Ein KPI zur zum Geldfluss im HR ist hierbei doch auch der Erfüllungsgrad je  Region/Abteilung/Mitarbeiter*in/Projekt

Mein Ansatz wäre, die ganzen Performance Werte aller Mitarbeiter zu PowerBI ins Reporting zu werfen und hübsche CEO-gerechte dynamisch klickbare Auswertungen (fast von allein) zu erstellen.

📂 Zur Dokumentation: Ausbaufähigkeit eurer API-Beschreibung

ein Beispiel hierzu - Ich war sehr dankbar für eure Erläuterung per E-Mail zum Thema “GET EMPLOYEES” 

 

The GET-request URL is: https://api.personio.de/v1/company/employees?limit=200&offset=0

The 'offset' parameter needs to be utilised in order to receive "the next page" of employees.

The offset endpoint is actually behaving as a page parameter, meaning that offset needs to be multiplied per limit.

Offset should be used as page, starting from 1, and creating a request

  • with offset 0 or 1 => you get page 1 with the first 200 data sets
  • with offset 2 => you get page 2 with the data sets 201 - 400
  • with offset 3=> you get page 3 with the data sets 401 - 600

mit den offset-Werten bin ich noch nicht so sicher, ob das richtig ist!


The user also receives an info in the metadata, how many pages are there and which page the request pulled
 

 

 

variable Gehaltsanteile von anderen Systemen in Personio importieren

Das Thema ist für uns auch relevant. Subventioniertes Essen/Dienstwagen könnten so besser in die Lohnbestandteile importiert werden. Die Excel-Vorlage zum Import nutzen ist etwas Händisches. Davon wollen wir gern weg. 

Wir lesen mittlerweile Personio-Mitarbeiterinfos aus und nutzen die in MS Sharepoint Online für die Bestellabwicklung von Essen. Resultat ist ein automatischer Export 1x monatlich mit Mengen und Beträgen zum Essen (exakt wie die Excel-Vorlage von Personio). Das funktioniert alles automatisch - nur die Personio Import-Seite fehlt noch...

 

 

 

Eigentlich könnte man die Verwendung der API auch alles noch besser beschreiben für normale Büromenschen (nicht Fach-Informatiker):
 


 

 


Hallo hier mein Feedback zur API. Bisher fühlen sich die Beiträge mehr fachlich als technisch an. Ich bin in der technischen Leitung unserer Firma, mir geht es um eine generelle API für den programmatischen Zugriff auf Personios Funktionen und Daten, damit wir diese in unseren eigenen Systemen verarbeiten können.

  • Webhook Support für die verschiedenen Bereiche, damit externe Systeme darüber informiert werden können. In Recruiting bspw. "Stelle aktualisert", Angestellte "Daten wurden aktualisiert"
  • Abdeckung aller Bereiche: Wir benötigen zur Zeit vor allem Recruiting, wir haben aber auch Ideen zur Automatisierung für die Personalakte, zu den Dokumentvorlagen, selbst zu den Settings/Einstellungen.
  • Besseres Token Management. Ein Audit Trail ist hier zwingend. Ich muss wissen wann ein Token welche Daten abgreift. Derzeit kann ich Tokens nur schlecht eingrenzen, die Tokens sind global, laufen nicht ab und zeigen mir nicht ob sie verwendet wurden.
  • Tokens mit Scope: Es gibt einen Recruiting API Schlüssel + generische Tokens die man sich erstellen kann für ein paar Bereiche (Mitarbeiter, Anwesenheiten). Hier erwarte ich mehr Granularität und keine künstliche Unterscheidung.
  • Dokumentation. Ich bvenötige Code Beispiele, Playgrounds, Best Practices. Die aktuelle Dokumentation ist ein Schatten dessen was ich als Kunde erwarte.
  • Best Practice: Es gibt soviele großartige APIs. Allen voran die Stripe API. Ich erwarte von Personio den gleichen Anspruch und dass hier Inspirationen eingetragen werden.
  • JSON-first. XML als einzige Alternative in modernen APIs, das erwarte ich von SAP aber nicht von Personio. Ich frage mich bis heute, wieso die Recruiting API auf XML basiert. XML ist fein für mich, aber nur als eine von vielen Alternativen zu JSON.
  • Support: Ich hab seit nun fast einem Jahr einen minimalen Bug in der Recuriting API gemeldet, wo sämtliche Line Feeds beim übertragen verloren gehen. Ich erwarte mir hier einen effektiveren technischen Support. Der Support/Discussion im Developer Hub ist extrem verwaist, steht in direkter Konkurrenz zur Community. Man wird gehört, aber genau einmal und dann ist im Normfall Stille.
  • Transparenz & Roadmap: Roadmap, was ist geplant? Was kann man erwarten? Ihr kündigt die API 2.0 an und fragt nach Feedback. Ich wünsche mir hier eine List geplanter Funktionen mit der Möglichkeit Feedback darauf zu geben. Das ist viel effektiver als eine Wunschliste hier aufzuschreiben, da ich weder den Kontext noch den Fortschritt des Projekts kenne.

Danke & Viele Grüße


Vielen Dank für die Verlinkung!

In meinem Post 

 habe ich ja bereits ein bisschen was geschrieben:

 

Aktuell können die Leserechte pro Attribut einzeln eingestellt werden. Das ist super.

Die Schreibrechte wiederum gibt es entweder ganz oder gar nicht. Das ist nicht gut.

Aus unserer Sicht wäre es extrem wichtig, dass auch die Schreibrechte pro Attribut eingestellt werden können. - identisch zu den Leserechten.

Wir haben zb Bedenken, dass die Gehaltsinformationen ebenfalls einfach mit beschreibbar sind. Wir möchten diese (und ein paar andere) gern ausgrenzen und gar nicht von extern beschreibbar machen.


Es wurde ja bereits vieles hierzu geschrieben. Daneben fehlt uns die Recruiting API (und ein XML Export sehe ich nicht als API an 😉).


Hallo,

am Wichtigsten ist uns, dass alle Datenfelder über die API übertragen werden können. Insbesondere auch die für die Zukunft terminierten Änderungen (Stundenanzahl, Auszeiten, etc.) - sowohl das Stammdatum an sich als auch der Zeitpunkt zu dem die Änderung wirksam wird.

Aus unserer IT habe ich noch eine Bitte mitgenommen:

Wenn man die API benutzt und Personio hat einen Fehler (z.B. heute Nacht bekamen wir einen "We've got some trouble | 500 - Internal server error"), dann kommt aktuell eine gerenderte HTML Seite zurück. Die API sollte hier eine einfache Fehlerbeschreibung (Plaintext, JSON o.ä.) zurückliefern. Schließlich landet die Ausgabe in unserem Log und spammt dort unnötigerweise über 1000 Zeilen bei nur einem Fehler. Außerdem ist es fast unmöglich die eigentliche Fehlerbeschreibung zu finden.

 

Hoffentlich kommt hierbei mehr raus als bei der DATEV-Schnittstelle - eine verlässliche Roadmap (wie auch schon von anderen gefordert) wäre ein echter Fortschritt!

 

Viele Grüße

Katha


Hallo zusammen,

 

ich bin kein IT-Experte, möchte aber auch gern einmal meinen Senf zum Thema Schnittstelle kund tun ;)

 

Wir nutzen ja bereits diverse Partnerprogramme aus dem Marketplace und würden uns da einfach eine Erweiterung der Schnittstellen wünschen.

 

Es ist immer sehr mühsam, wenn man bei Lanes&Planes, Shyftplan, Circula usw. alle Genehmigungsschleifen neu anlegen muss, obwohl in Personio bereits die Daten dazu bereit liegen. Auch ist es ärgerlich, dass man mit Shyftplan zwar eine tolle Ergänzung bzgl. Schichtplanung, Erfassung von Arbeitszeiten usw. hat, es jedoch keinerlei Möglichkeit gibt, die Zeiten sauber in den Anwesenheitsreiter von Personio zu integrieren, um nicht in beiden Programmen parallel arbeiten zu müssen. Auch die DATEv-Schnittstelle ist meiner Meinung nach noch ausbaufähig - wir schicken als Excel-Export die Lohn- und Gehaltsdaten rüber, weil die An- und Abwesenheiten nicht automatisch übermittelt werden können. Hier fehlt uns die Erweiterung der Schnittstelle, um das Thema Abwesenheiten usw.

Es wäre daher wünschenswert, wenn die Schnittstellen hier eine Erweiterung kriegen könnten, bevor man immer weitere Partnerprogramme aufnimmt und sich die Schnittstellen nur um das Thema Vor- und Nachname, sowie E-Mailadressen dreht.

 

Liebe Grüße


Hallo liebe Community 👋

Der Integrations Month ist nun vorbei und ich bin ganz überwältigt davon wieviel Feedback wir bekommen haben! Danke für die vielen Kommentare dazu, wie wir die API verbessern können. Das hilft uns dabei unser Angebot noch besser an Eure Bedürfnisse anzupassen 💪

Die nächsten Tage werde ich alle Kommentare auswerten, mit unseren Produktmanager*innen teilen und mich dann noch einmal zu einem Recap Post bei Euch melden.

Aber auch wenn der Integrations Month vorbei ist, könnt ihr selbstverständlich weiterhin fleißig mitdiskutieren. Wir freuen uns auf weiteren Austausch!

Liebe Grüße 🌷


Hallo,

ich möchte auch noch meinen Wunsch nach mehr Api-Abdeckung von Datenfeldern kund tun. So wäre z.B. ein Zugriff auf On- und Offboarding-ToDos sehr hilfreich (nicht nur) für das IT-Service-Desk.

 

Gruß

Armin


Wir würden uns wünschen, dass man nicht immer alle Abwesenheitsdaten abrufen muss und erst dann filtern kann, sondern dass man vorher bereits filtern kann. Wir nutzen zb für einen Workflow nur die Art Homeoffice, alles andere wird nicht benötigt.


Hallo,

 

ich habe dazu Rückmeldung von unseren ITlern und Entwicklern für Schnittstellen bekommen:

  • Zugriff auf Benutzerkonfigurationen, wie die Sprache
  • Ergebnissen nach Attributen per Query-Parameter filtern, bspw. MA anhand des employment_type filtern, um nur interne MA zu exportieren → aus Datenschutz und Datensparsamkeitsgründen wäre es wirklich zu präferieren, wenn man erst filtert und dann exportiert anstatt andersherum
  • Dokumentation der benötigten Berechtigungen, die man für die Vergabe der Credentials festlegt
  • Aktuell fehlt das JSON, bzw. die einzelnen Parameter in der Doku, die bei einem Request zurückgegeben werden. Um hier einzelne Details herauszubekommen, muss man immer einen Request durchführen. Dies ist vielleicht nicht immer sinnvoll, wenn man direkt mit dem Produktivsystem arbeitet. Man könnte einen Beispiel-Response an jedem Request in der Doku anheften.
  • Endpunkt für Abruf aller offenen Aufgaben

 

Viele Grüße

Sandra


Auch von meiner Seite herzlichen Dank für die Rückfrage. 
Wir wünschen uns eine Notification-API, die per push oder pull die bisher per E-Mail an die User gesendeten Handlungsaufforderungen zur Verfügung stellt. 

Hintergrund: Personio ist großartig, wird jedoch von dem überwiegenden Teil der User nicht permanent genutzt. Die tägliche Arbeit findet in einem anderen System statt, über welches die User auch andere Handlungsaufforderungen erhalten. 

Was?
Information über Tasks aus “Meine Aufgaben” alternativ per API oder Webhook anstelle einer E-Mail zur Verfügung stellen.

Warum?

E-Mail wird in immer mehr Unternehmen lediglich für externe Kommunikation genutzt. Interne Kommunikation und Übermittlung von Aufgaben erfolgen zunehmend über andere Tools (z.B. Slack, MS Teams oder andere Lösungen wie z.B. persönliches Dashboard).
Das verfolgte Ziel ist es hierbei, Mitarbeitende mit so wenig Tools arbeiten zu lassen wie möglich.

Die Aufforderung, in Personio aktiv werden zu müssen, wird aktuell Mitarbeitern ausschließlich per E-Mail zur Verfügung gestellt. Sinnvoll ist es, diese Information über bestehende Kanäle den Mitarbeitern zur Verfügung zu stellen. Hierzu ist ein Zugriff auf die notwendige Information holend per API oder liefernd per Webhook denkbar. 

Wie?

Beim Trigger zum versenden einer E-Mail aus Personio heraus an den Mitarbeiter mit der Aufforderung eine Aufgabe in Personio zu erledigen, könnte diese entweder:

a) in einem Auftragspool bis zum Abruf per API gepuffert werden oder
b) an eine in den Einstellungen hinterlegte URL in strukturierter Form als Webhook gepushed werden.

Die strukturierte Nachricht (z.B. JSON oder XML) müsste nur die Informationen enthalten, die schon jetzt in der E-Mail übermittelt werden:

1. E-Mail des Empfängers,
2. Subject
3. Copytext
4. Call to Action URL auf die Personioseite
5. ggf. den Namen

 


Danke für den Einsatz und die Möglichkeit, dass man sich hier als Anwender einbringen kann. Ist nicht selbstverständlich heutzutage.

Es wurde oben ja bereits angedeutet und ich hoffe ich bin damit nicht zu spät: ein API-Endpunkt zum Abrufen von offenen Stellen im JSON-Format wäre super. Wenn diese noch analog der übrigen API gestrickt ist: optimal.


@laOlaWeb wir nutzen dafür den XML-Feed.

Personio Recruiting API


Natürlich, wir auch. Aber als JSON wäre es schon komfortabler.


Es gibt scheinbar nur einen “Recruiting-API-Schlüssel”, alle weiteren Schlüssel sind für Attributswerte.

Ich fände es gut, für externe Anbieter/Stellenportale jeweils eigene Recruiting-Schlüssel anlegen zu können, sodass ich die Kontrolle habe und diese individuell auch abschalten kann. Der Tooltip sagt, beschütze den Token mit deinem Leben, aber ich muss den ja ausgeben, wenn ich externe anbieter anbinden möchte. Wenn ich die Unternehmens-ID und den Token erst mal rausgegeben habe, dann kann ich den Token nicht mal per Hand ändern um dem externen Anbieter den zugriff abzuschalten...


Hallo Zusammen,

gerne hätte ich das Feature wie hier beschrieben:
 

 

Und hier schonmal angefragt und vorangekündigt:
https://developer.personio.de/discuss/616d185130ef8e0019116661

Da es so etwas kleines ist, sollte das ja rasch implementiert sein.

Herzlichen Dank schonmal


Hallo zusammen,

 

cool dass ihr Feedback einsammelt:

Mein Senf dazu:

  • GraphQL statt REST (oder zusätzlich zu REST)
  • persönliche API Credentials zusätzlich zu den globalen API Zugangsdaten

Es wäre super, wenn man persönliche API Tokens ermöglicht. Scope ist damit User-Beschränkt.

Viele Mitarbeiter (vor allem Entwickler) würden gerne einige Themen in ihrem Profil über API ändern, dürfen dies aber nicht, da der API Client “global” gilt.

 

Grüße

tns

 


Hallo,

aktuell fehlt uns akut die Zugriffsmöglichkeit auf das Feld “Einmalige Vergütungen”.

Generell sehe ich hier aber viele vernünftige Vorschläge und denke “API first” wäre generell das wünschenswerte Paradigma.

Danke und Grüße

Max


Hallo zusammen, 

mir fehlt aktuell die Möglichkeit bei den Mitarbeiter Stammdaten die Berechtigungen auf Attribute zu filtern. 

Ich möchte z.B. nicht, dass mit einem lesenden Key die Gehaltsdaten der Abteilung Geschäftsführung gelesen werden können.

Vielleicht habe ich das aber gerade auch übersehen.

 

Danke 

Andreas


Hallo,

 

ich habe dazu Rückmeldung von unseren ITlern und Entwicklern für Schnittstellen bekommen:

  • Zugriff auf Benutzerkonfigurationen, wie die Sprache
  • Ergebnissen nach Attributen per Query-Parameter filtern, bspw. MA anhand des employment_type filtern, um nur interne MA zu exportieren → aus Datenschutz und Datensparsamkeitsgründen wäre es wirklich zu präferieren, wenn man erst filtert und dann exportiert anstatt andersherum
  • Dokumentation der benötigten Berechtigungen, die man für die Vergabe der Credentials festlegt
  • Aktuell fehlt das JSON, bzw. die einzelnen Parameter in der Doku, die bei einem Request zurückgegeben werden. Um hier einzelne Details herauszubekommen, muss man immer einen Request durchführen. Dies ist vielleicht nicht immer sinnvoll, wenn man direkt mit dem Produktivsystem arbeitet. Man könnte einen Beispiel-Response an jedem Request in der Doku anheften.
  • Endpunkt für Abruf aller offenen Aufgaben

 

Viele Grüße

Sandra

Sehe ich genauso. Darüber hinaus, wäre es sehr hilfreich auch nach speziellen Metadaten (je Typ) filtern zu können. Das erspart in einigen Fällen eine Middleware.


Hallo @helgetan,

in den Einstellungen zu den API-Zugriffsdaten kannst Du festlegen, welche Attribute gelesen werden dürfen, mehr dazu in diesem Artikel. Leider gibt es aber aktuell keine Möglichkeit es so einzustellen, dass die Attribute nur für bestimmte Mitarbeitende ausgegeben werden.

Das Produktteam ist sich dem bewusst und überprüft im Moment Verbesserungsmöglichkeiten, um die Zugriffsrechte für API-Zugriffsdaten noch granularer gestalten zu können. Leider kann ich Dir aber noch keine weiteren Informationen zu Umfang und Veröffentlichungszeitpunkt nennen. 

In der Community und über den Produktnewsletter werden wir Euch aber auf dem Laufenden halten!

 

Liebe Grüße
Valentin


Hallo @exactt 

über den Employee Endpunkt der API wird das Attribute nicht ausgegeben, das ist richtig. Es gibt aber einen Workaround: Die gewünschten Informationen lassen sich in den individuellen Berichten abbilden. Diese Berichte können dann über die API abgerufen werden, mehr dazu in diesem Artikel.

Ich hoffe, ich konnte Dir damit helfen.

 

Liebe Grüße
Valentin


Hallo @Valentin, grundsätzlich gut, aber ich brauche schreibenden Zugriff. Hört sich aber nicht so an, als wäre das auf diesem Weg möglich, oder? Aber danke. Grüße Max