Discussions
What is the thinking behind the GET /company/employees API?
I'm currently creating a C# client for integrating Personia with out microservices.
Most of the endpoints seem sensible, but perhaps a better understanding of the design thinking will help me design better client code.
Whereas I would normally expect calling the system to provide the consumer with just the relevant data, it seems calling GET "/company/employees API" provides a response which is packed with metadata which bloats the response.
Moreover, it does not seem like there is any reliable way to create a client which accesses custom fields, as these get attribute names like "dynamic_21827", which I expect are not stable between Personio environments and I'm not even clear whether they are stable within the same Personio environment over any extender period of time?
Moreover, I'm a bit wary about using the "label" to identify fields, since I expect these should be for UI/UX and I would imagine even within the same language, these may evolve over time.
Is there no concept of an "API Name" which would abstract the label from the functionality provided for developers, while providing developers with a stable reference?
If the metadata is stable, is there no way to request simplified feedback to reduce API consumption?