Everything an AI agent can do with the Personio API.

A reference guide for building AI agents: every method, how to authenticate, and the permissions each one needs.

Endpoints19
API versionv1
Last updated23 June 2026
Orientation

How the Personio API works.

The Personio API is how an app or AI agent works with a company's HR records: listing and updating employees, logging and editing attendances, booking and cancelling time off, uploading documents, and pulling saved reports. Access is granted through an API credential that an admin turns on area by area as read or write, and narrows further to a chosen set of employee fields, so a credential can only ever see and change what it was set up for. Personio can also push a notification to a webhook when a record changes, instead of being polled.

19Endpoints
5Capability groups
11Read
8Write
8Permissions
Authentication
Every request carries a bearer token. The token is obtained by posting an API credential, a client id and client secret, to the auth endpoint, which returns a token that is valid for 24 hours. Stable tokens begin with a papi- prefix and the current token is also returned in the response header of each successful call, so an integration can rotate it without re-authenticating. A missing, expired, or invalid token returns 401, at which point the credential is exchanged again.
Permissions
Access is governed per API credential. When a credential is created, an admin chooses which areas it can reach, such as employees, attendances, time off, and documents, and whether each is read, write, or both. For employee data it goes finer: the readable and writable attributes are whitelisted field by field, so fields that were not granted are simply omitted from responses rather than refused. Two credentials against the same company can therefore have very different reach.
Versioning
Personio versions by path, not by a dated header. The v1 Personnel Data API is the stable, broadly used generation and the subject of this reference. A newer v2 line, with its own auth, adds person, attendance, and absence endpoints and is where new features arrive. The v1 Attendances and Projects endpoints are deprecated with a final date of 30 August 2026, and posting auth credentials in the query string is being removed on 4 December 2026.
Data model
Records are organised around the employee under /v1/company. Core details sit at /v1/company/employees, with an employee's leave allowance at /v1/company/employees/{employee_id}/absences/balance. Account-wide collections sit alongside: /v1/company/attendances for logged hours, /v1/company/time-offs and /v1/company/time-off-types for day-based leave, /v1/company/documents for files, and /v1/company/custom-reports for saved reports. Responses are JSON, wrapped in a success flag plus a data array and pagination metadata.
Connect & authenticate

Connection & authentication methods.

How an app or AI agent connects to Personio decides what it can reach. Access runs through one route, an API credential made of a client id and client secret that is exchanged for a short-lived bearer token, and that credential carries exactly the areas and the employee attributes an admin chose for it when it was created.

Ways to connect

REST API (v1 Personnel Data)

The v1 Personnel Data API answers at api.personio.de/v1/company. Responses are JSON, wrapped in a success flag plus a data array and pagination metadata. This is the stable, broadly used generation and the subject of this reference.

Best forConnecting an app or AI agent to Personio employee, attendance, and absence data.
Governed byThe API credential and the areas and attributes whitelisted on it.
Docs ↗

REST API (v2)

A newer v2 line adds person, attendance, and absence endpoints with its own auth and token revocation, and is where new features land. It runs in parallel with v1 and is the migration target for the deprecated v1 Attendances and Projects endpoints.

Best forNew integrations and features not present on v1.
Governed byThe API credential and its v2 scopes.
Docs ↗

Webhooks

Webhooks deliver a notification when a record changes, removing the need to poll. A subscription is registered against a chosen event, and Personio posts the change to a receiver URL when it happens. The webhook scope, read or write, must be present on the credential.

Best forReacting to employee, attendance, or absence changes without polling.
Governed byThe credential that manages subscriptions and its webhook scope.
Docs ↗
Authentication

API credentials (bearer token)

An API credential, a client id and client secret, is posted to the auth endpoint and exchanged for a bearer token valid for 24 hours. Stable tokens begin with a papi- prefix, and the current token is returned in the response header of each successful call so it can be rotated without re-authenticating. The credential carries the areas and attributes an admin granted it.

TokenShort-lived bearer token (papi- prefix)
Best forServer-to-server access scoped per credential
Docs ↗
Endpoint reference

Every Personio API method.

Filter by method, access, or permission, or search any path. Select a row for version detail, rate limits, the related webhook event, and the source.

MethodEndpointWhat it doesAccessPermissionVersion

Employees

List employees, read one by id, create and update employees, and read an employee's leave allowance.5

Needs the employees area set to read on the credential. Only the employee attributes whitelisted on the credential are returned; any field not granted is omitted from each record.

Acts onemployee
Permission (capability)Employees: read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Needs the employees area set to read. Which fields come back depends on the readable attributes whitelisted on the credential; restricted fields are omitted rather than refused.

Acts onemployee
Permission (capability)Employees: read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Needs the employees area set to write. Only attributes whitelisted as writable on the credential can be set; a supervisor must reference an existing employee id.

Acts onemployee
Permission (capability)Employees: write
VersionAvailable since the API’s base version
Webhook eventemployee_changed
Rate limitStandard limits apply

Needs the employees area set to write. Only attributes whitelisted as writable can be changed; the email field cannot be updated through this endpoint.

Acts onemployee
Permission (capability)Employees: write
VersionAvailable since the API’s base version
Webhook eventemployee_changed
Rate limitStandard limits apply

Needs the employees area set to read. Returns the remaining balance per time off type for the named employee.

Acts onabsence balance
Permission (capability)Employees: read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Attendances

List logged attendance periods, add new ones for one or many employees, and update or delete a period.4

Needs the attendances area set to read. This v1 endpoint is deprecated with a final date of 30 August 2026; the v2 attendance-periods endpoints are the replacement.

Acts onattendance period
Permission (capability)Attendances: read
VersionDeprecated 2026-01-31 · Sunset 2026-08-30
Webhook eventNone
Rate limitStandard limits apply

Needs the attendances area set to write. Accepts a list, so several employees can be logged in one call. Deprecated v1 endpoint, final date 30 August 2026.

Acts onattendance period
Permission (capability)Attendances: write
VersionDeprecated 2026-01-31 · Sunset 2026-08-30
Webhook eventattendance_changed
Rate limitStandard limits apply

Needs the attendances area set to write. Deprecated v1 endpoint, final date 30 August 2026; migrate to the v2 attendance-periods endpoints.

Acts onattendance period
Permission (capability)Attendances: write
VersionDeprecated 2026-01-31 · Sunset 2026-08-30
Webhook eventattendance_changed
Rate limitStandard limits apply

Needs the attendances area set to write. The removal cannot be undone. Deprecated v1 endpoint, final date 30 August 2026.

Acts onattendance period
Permission (capability)Attendances: write
VersionDeprecated 2026-01-31 · Sunset 2026-08-30
Webhook eventattendance_changed
Rate limitStandard limits apply

Time off

List day-based time off, read one by id, book a new request, delete one, and list the available time off types.5

Needs the time off area set to read. Returns each type's id and name, needed before booking a time off against a type.

Acts ontime off type
Permission (capability)Absences: read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Needs the time off area set to read. Covers absences measured in whole days; hourly absences are handled by the absence-periods endpoints.

Acts ontime off period
Permission (capability)Absences: read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Needs the time off area set to read. Returns the period's dates, type, and the employee it belongs to.

Acts ontime off period
Permission (capability)Absences: read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Needs the time off area set to write. Requires an employee id, a time off type id, and a start and end date; this creates real leave on the record.

Acts ontime off period
Permission (capability)Absences: write
VersionAvailable since the API’s base version
Webhook eventabsence_changed
Rate limitStandard limits apply

Needs the time off area set to write. Cancels real leave for the employee, and the removal cannot be undone.

Acts ontime off period
Permission (capability)Absences: write
VersionAvailable since the API’s base version
Webhook eventabsence_changed
Rate limitStandard limits apply

Documents

List the document categories available in the account and upload a file to an employee under a category.2

Needs the documents area set to read. Returns each category's id and name, needed to pick a category before uploading a file.

Acts ondocument category
Permission (capability)Documents: read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Needs the documents area set to write. The request must be multipart/form-data with the file, the employee id, and a category id. This endpoint carries its own separate rate limit because uploads are heavier than ordinary calls.

Acts ondocument
Permission (capability)Documents: write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limit60 requests per minute

Reports

List the saved custom reports, read a report's data by id, and list the columns a report can return.3

Needs read access to the underlying areas a report draws on. Returns each report's id and metadata; the reports listed are those the credential can access.

Acts onreport
Permission (capability)Employees: read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Needs read access to the areas the report draws on. A report can return whole-company data in one call, so the credential's whitelisted attributes bound which columns it sees.

Acts onreport
Permission (capability)Employees: read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Needs read access. Returns the set of column labels available, used to interpret the columns a report returns.

Acts onreport column
Permission (capability)Employees: read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply
No endpoints match those filters.
Webhooks

Webhook events.

Personio can notify an app or AI agent when an employee record, an attendance, or an absence changes, instead of the app repeatedly asking. A subscription is registered against a chosen event, and Personio posts the change to a receiver URL when it happens. The webhook scope, read or write, must be present on the credential that manages subscriptions.

EventWhat it signalsTriggered by
Employee created or updatedFires when an employee record is created or changed. The subscription posts the change to a receiver URL, and only reports data the subscribing credential is permitted to see./v1/company/employees
/v1/company/employees/{employee_id}
Attendance created, updated, or deletedFires when an attendance period is added, changed, or removed. The subscription posts the change to a receiver URL for the events the credential is allowed to receive./v1/company/attendances
/v1/company/attendances/{id}
/v1/company/attendances/{id}
Absence created or deletedFires when a time off period is booked or cancelled. The subscription posts the change to a receiver URL, bounded by what the credential can see./v1/company/time-offs
/v1/company/time-offs/{id}
No events match that search.
Rate limits & pagination

Rate limits, pagination & request size.

Personio limits how often a credential can call the API and answers a call that goes over with a 429 status. The limit is counted per credential, with a separate, larger ceiling counted per source IP address on the v1 endpoints, and the authentication endpoint has its own tighter limit.

Request rate

Personio limits how often a credential can call the API and returns a 429 status when a call exceeds the limit, with X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers describing the current state. The limit is counted per credential, and there is a separate, larger ceiling of 2000 requests per minute counted per source IP address on the v1 endpoints. The authentication endpoint is limited more tightly, to 60 requests per minute, after which there is a 60 second cool-down before a new token can be requested. The practical model is to read the rate-limit headers and back off on a 429 rather than to assume a single fixed number across every endpoint.

Pagination

List endpoints page with limit and offset query parameters and return a metadata block alongside the data, carrying the total number of elements, the current page, and the total page count. The default page size and ceiling vary by endpoint, so an integration should read the metadata to know how many pages remain rather than assuming a fixed size.

Request size

Requests and responses are JSON. Documents are uploaded as multipart/form-data against the documents endpoint, attaching a file to an employee under a chosen category. No single overall payload size limit is documented across the v1 API; the documents endpoint carries its own separate rate limit because uploads are heavier than ordinary calls.

Errors

Status codes & error handling.

The status codes an agent should handle, and what to do about each.

StatusCodeMeaningWhat to do
400Bad RequestThe request was malformed, such as an invalid parameter or a body that could not be parsed.Check the parameters and body against the endpoint reference and resend. The body carries success false with an error code and message.
401UnauthorizedThe bearer token is missing, expired, or invalid.Exchange the API credential for a fresh token at the auth endpoint, then retry with the new token in the Authorization header.
403ForbiddenThe token is valid but the credential lacks the area or attribute the request needs.Widen the credential's scopes or whitelisted attributes in the API credential wizard to cover the request.
404Not FoundThe resource does not exist, or the path is wrong.Confirm the employee id, time off id, or report id, and the path, then retry.
429Too Many RequestsThe rate limit was exceeded for the credential or the source IP address.Read the X-RateLimit-Reset header, wait until the window resets, and back off before retrying.
500Internal Server ErrorAn unexpected error occurred inside Personio.Retry after a short pause, and contact Personio support if it persists.
Versioning & freshness

Version history.

Personio runs two API generations side by side. The v1 Personnel Data API, carried in the request path, is the stable, broadly used one and the subject of this reference; a newer v2 line adds person, attendance, and absence endpoints with their own auth and is where new features land. Both are versioned by path, not by a dated header.

Version history

What changed, and when

Latest versionv1
v1Current version
Stable Personnel Data API

Personio versions by path. The v1 Personnel Data API is the stable, broadly used generation and the subject of this reference. It does not mint dated versions; changes ship continuously and are recorded in the changelog. The dated entries below are notable recent changes, newest first.

What changed
  • 2026-06-04: Posting auth credentials in the query string on /v1/auth deprecated, with removal set for 4 December 2026.
  • 2026-02: Reporting API v2 endpoints introduced for the new report builder on the analytics 2.0 platform.
  • 2026-01-31: v1 Attendances and Projects endpoints deprecated, with a final date of 30 August 2026.
2026-03-01Feature update
Status filter on v2 persons

A status filter was added to the v2 list persons endpoint, letting an integration filter by employment status.

What changed
  • Added a status query filter to GET /v2/persons.
2025-08-01Feature update
Webhooks for the Person entity

Webhooks for the Person entity were made available to all customers with Public API access, so an app can be notified of employee changes instead of polling.

What changed
  • Person-entity webhooks rolled out to all Public API customers.
2023-09-01Feature update
Improved stable bearer token

Stable tokens with a papi- prefix were introduced, valid for 24 hours and returned in the response header of each successful call so an integration can rotate the token without re-authenticating.

What changed
  • Stable papi- prefixed tokens, valid 24 hours, returned in the response header for rotation.
2023-07-01Feature update
IP-based rate limiting on v1

A rate limit of 2000 requests per minute, counted per source IP address, was added on the v1 endpoints in addition to the per-credential limit.

What changed
  • Added a 2000 requests-per-minute ceiling per source IP on v1 endpoints.

This reference covers the v1 Personnel Data API. The v1 Attendances and Projects endpoints are deprecated with a final date of 30 August 2026; the v2 line is their replacement. Track the changelog for migration deadlines.

Personio API changelog ↗
Questions

Personio API, answered.

How does an agent authenticate to Personio?+
With a bearer token. An API credential, a client id and client secret, is posted to the auth endpoint, which returns a token valid for 24 hours. Stable tokens start with a papi- prefix, and the current token is also returned in the response header of each successful call so it can be rotated without re-authenticating. A missing or invalid token returns 401, at which point the credential is exchanged for a fresh token.
What scopes or permissions does the API use?+
Real per-credential scopes. When an API credential is created in Personio, an admin chooses which areas it can reach, such as employees, attendances, time off, and documents, and whether each is read, write, or both. Employee data is narrowed further: the readable and writable attributes are whitelisted field by field. A credential can only ever act within those choices, and fields it was not granted are left out of responses rather than refused. This is why scoping an agent matters: a single credential can be made to reach a lot or very little.
What are the rate limits?+
Personio counts requests per credential and returns a 429 when a call goes over, with X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers showing the current state. A separate, larger ceiling of 2000 requests per minute is counted per source IP address on the v1 endpoints, and the authentication endpoint is limited to 60 requests per minute with a 60 second cool-down. The right approach is to read the headers and back off on a 429 rather than plan against one fixed number.
How does an agent get notified of changes instead of polling?+
Through webhooks. A subscription is registered against a chosen event, and Personio posts the change to a receiver URL when an employee record, attendance, or absence changes. The webhook scope, read or write, must be present on the credential that manages subscriptions, and a subscription only ever reports data the credential is permitted to see.
What is the difference between time-offs and absence periods?+
They measure leave differently. The v1 time-offs endpoints handle day-based absences, such as a multi-day holiday, listing, creating, and deleting them under /v1/company/time-offs. Hourly absences, measured in part-day periods, are handled by the absence-periods endpoints. Day-based time off remains the common case on v1; the newer v2 line consolidates both into a single absence-periods model.
Why is an employee field missing from the response?+
Because the credential was not granted it. Personio whitelists readable employee attributes per credential, so any field that was not selected in the credential wizard is simply omitted from the response rather than returned empty or refused with an error. To read a missing field, the credential's readable attributes have to be widened to include it.
Does Personio have an official MCP server?+
No. As of June 2026 Personio does not publish a first-party Model Context Protocol server. Several third-party MCP servers wrap the Personio API, but none are run by Personio, so an agent connects through the v1 REST API and its API credentials.
Related

More hr API guides for agents

What is Bollard AI?

Control what every AI agent can do in Personio.

Bollard AI sits between a team's AI agents and Personio. Grant each agent exactly the access it needs, read or write, area by area, and every call is checked and logged.

  • Set read, write, or full access per agent, never a shared Personio credential.
  • Denied by default, so an agent reaches only what has been explicitly allowed.
  • Every call recorded in plain English: who, what, where, and the decision.
Personio
People Ops Agent
Read employee directory ResourceOffReadFull use
Book and delete time off ActionOffReadFull use
Read compensation attributes ResourceOffReadFull use
Per-agent access, set in Bollard AI, not in Personio