Ultimately, the API should be open to incorporate all “fields” available for each employee.
We are currently stuck in pulling manual files from Personio to our salary review tool, as we are unable to set up an API integration which pulls date of last salary change, fix salary, bonus, and reoccurring compensation

The API is currently really restrictive when it comes to the “GET” part of data. From an analytics/Business Intelligence perspective it would be important to have: 

• either an integration with Snowflake 
• allow a GET request via API on the most important tables

From our perspective it would be important to generate more insights into the recruiting processes as well as tenure and position changes. Therefore the following data should be available via API: 

• get on applications
• get on application status changes
• get on applicants

Alternatively it would be good to be able to export custom reports via API - this would allow for the greater flexibility when it comes to creating insights for the people partners and recruiters.

Thank you @Astrid Friis & @FriederikeThies for your input on our API!

I am currently analyzing all comments that came in during the Integrations Month, both in the International Community and the German one. Once I am done going through all comments, I will also share the results with the Product Managers and the rest of the team and discuss them. At the end of the process, I will share a Recap Post with all of you.

But in case you should have any further input, feel free to comment here or also send me a private message

Hi Astrid, 

I would have expected that Personio is build API first, meaning, that everything than can be done via the interface can be done via an API. I was pretty surprised to find out that not only this is not the case, but there is a lot of data that we are unable to retrieve (e.g. to recruitement data) in any way. 

Currently our HR team is expecting recruitement KPIs (e.g. time to hire) and I’m completly unable to deliver. 

Ideal would be:  

1. Documented and versioned API to be able to retrieve all application information that is there (maybe even with the ability to hash PID based on the user role) 
2. Nice to have: Reach out to the major data pipeline providers (Fivetran, Stich, ...) in order to ask them for a data pipeline into the major DWHs such as Snowflake, Bigquery & Redshift. I’m sure there should be quiet a lot of interest in the market. 

If that’s somehow impossible it would help ( even though it’s not ideal) to be able to schedule custom reports on a cron as a CSV and send them to a AWS S3 bucket. 

Thanks

Alex 

Hello,

The biggest and most dangerous problem that I see with the API is that it does not have permissions inheritance:

If some user is given access to the API key generation, no matter what restrictions the user account has, if he is allowed API control, the user can select any permission for an API key and use that in order to view otherwise restricted data.

In effect this means that in order for any developer to create an API key he’s going to need to go through HR / whoever has API access and receive it, rather than himself being able to create the key himself.

Example :

I create a bot@mycompany.com user in order to synch some personio data with the google calendar.

The bot account receives usual employee access from HR.

I ask for the bot account to have API permissions, so that a shareable account is able to have API generation capability, and not have API generation tied to individuals ( that may be replaced some time down the line and the API is under nobody’s control ) .

I get the bot account API permissions. Sweet, I can generate my own API keys and select needed scopes and attributes.

Even though bot@ has No access to view the Salary data in the Web interface, I select it for the API key.

Now I can view the entire company’s salary data.

This is such a big problem that I even wonder if it’s something in our settings that’s not correctly configured or if this is a general problem / if somehow this was maybe even intended ?

Hi @Alexander Rupp,

thank you for your input! 

So the Integrations Team is currently working on the foundation for our API 2.0. The idea is to enable all other Teams within Personio to make their API endpoints public for our customers to use them. In the ideal vision of the team, Personio will be built API first. To be fair though, it hasn’t been the focus in the last years though, so it will take some time to get there. 

Also thank you to @cvasiliu!

We definitely are aware of this struggle and understand the problem. But it is also good for us to see when the request is being brought up regularly, as it helps us estimating the significant of the feature request. As also mentioned above, we are doing a lot of foundation work at the moment. But as soon as this is done, we will focus more on the UX side of things, where also the creation of Credentials would be tackled. 

I hope I could already clarify this a bit. But please let me know, in case you have more questions.

Also, we are currently trying to understand the IT Persona a little bit more, since they are the ones implementing the functionality on the customer’s side. So if you or your colleagues would be interested in talking to us, please let me know and I would happily schedule a meeting! The same obviously goes for @Astrid Friis and @FriederikeThies :)

“we will focus more on the UX side of things, where also the creation of Credentials would be tackled. “

Just to be clear, this has nothing to do with the UX, the problem is in the backend. You allow attribute selection over attributes that the user has no access to.

Cheers!

Hi together, 

in this posting you find a first update for the API experience: 

Stay tuned for more. :) 

Best, 
Lena