Discussions

Hi everyone,

For one employee, a custom attribute set in the UI is returned correctly by the single-employee endpoint, but with the old value by the list endpoint. The mismatch has lasted for hours. We use this field to control access provisioning, so the stale value caused a user to be wrongly blocked.

Setup:

API v1, https://api.personio.de/v1
Custom attribute dynamic_XXXXXXXX (type “list”, a Yes/No dropdown)
The attribute is readable by our API credentials. It is returned by both endpoints, just with different values.

What we see for the same employee at the same time:

UI: YES
GET /v1/company/employees/{id} returns “Yes”
GET /v1/company/employees?limit=200&offset=N returns “No”
GET /v1/company/employees?email={email} returns “No”

Both endpoints return the same last_modified_at (2026-10-27T14:31:40+01:00). We saw the stale value in hourly runs for at least 3 hours, and it was still there when we re-checked. We set limit and offset explicitly, so this is not the “no limit/offset” case from this older thread: https://developer.personio.de/discuss/667a92771e33aa0019586d16

Expected: both endpoints return the current value, and last_modified_at changes when an attribute changes.

Actual: the list endpoint returns an outdated value that does not refresh, while the single endpoint is current.

What we ruled out:

Parsing: we compared the raw JSON from both endpoints.
Other records: we compared both endpoints for 12 other employees with the same attribute set to “No”. They agree on all of them. Only this record differs.
Whitelisting: the field is returned on both endpoints, so it is not a permission issue.

Side observation: on a second record of the same person, last_modified_at was 19:05:43+01:00 when the actual time was about 18:20 Berlin, so a timestamp in the future.

Questions:

Is the list endpoint served from a cache or index that can lag behind the single-employee endpoint? If yes, how long, and is it documented?
Why does last_modified_at stay the same while the values differ?
Is there a supported way to force a refresh, or to read current custom-attribute values in bulk?

Is anyone else seeing this? Thanks!