Discussions
Become a Partner

Discussions

Ask a Question
Back to All

Issues with API v2.0 – Missing Endpoints & Data Structure Concerns

2 days ago by Leonardo Malzacher

Dear Personio Team,

I am currently in the process of migrating our synchronization to API v2.0, as API v1.0 does not allow modifications to certain fields (e.g., email) after creating a person. However, I have encountered several issues with the new version that impact our integration.

1. Employment Handling in API v2.0

It appears that the backend data structure is undergoing a transition. In v2.0, you have split "Person" and "Employment," which is a great improvement for managing employment history (e.g., re-entering the company, changing positions).

However, there are significant limitations:

  • A person must be created with exactly one employment, which is fine.
  • Issue: It is currently not possible to add, update, or delete multiple employments for a person. This contradicts the intended flexibility of the employment structure.

2. Missing Endpoints for Internal IDs

In API v1.0, certain fields could be set using strings (e.g., office, cost centers, org units). In v2.0, these now require internal IDs, which introduces integration challenges:

  • There is no official API to fetch these IDs.
  • The only way to retrieve them is through the internal API used by your frontend, which is not documented nor intended.

To properly integrate with v2.0, we require the following endpoints:

  • GET /v2.0/offices
  • GET /v2.0/cost_centers
  • GET /v2.0/org_units (either combined or separate for departments and teams, e.g., /departments and /teams)
  • GET /v2.0/sub_companies (The attribute is marked as deprecated—what is the alternative?)

Furthermore, to enable full synchronization, CRUD support should be available for all entities requiring an ID.

3. Request Structure & Usability

The request format in v2.0 is often not intuitive. For example: 

"supervisor": { "id": "1234" }

or 

"position": { "title": "someTitle" }

Suggestion:

Allow setting values directly within the entity, making requests more manageable, especially in languages other than JavaScript. Example: 

"supervisor_id": "1617466",
"position_title": "sdf"

Conclusion

The most critical issue for us is (2), as we require a reliable way to synchronize employments and related attributes between our systems. Could you provide feedback on whether these issues will be addressed in future API updates?

Looking forward to your response!

Best regards,
Leonardo Malzacher