Personio De Personio API

What authentication does the Personio API use?

The Personio API uses Bearer token authentication. Obtain a token via POST /auth/token with your client_id and client_secret. The token is then included in the Authorization header for all subsequent requests. Through Jentic, token acquisition and refresh are handled automatically.

Can I manage employee absences in bulk?

The API handles absence periods individually via POST /absence-periods and PATCH /absence-periods/{id}. For bulk operations, agents iterate over employee IDs and create or update absence records sequentially. Each absence requires a person ID, absence type, start date, and end date.

How do I access recruiting data through Jentic?

Search Jentic for 'list recruiting applications' to discover GET /recruiting/applications. Load the schema and execute to retrieve application records. Related endpoints include GET /recruiting/jobs for positions, GET /recruiting/candidates for candidate profiles, and GET /recruiting/categories for job categories.

What HR data can I access through the Personio API?

The API covers persons (employee records), employments (job history), absence periods (leave tracking), attendance periods (timesheets), projects, compensations (salary data), organizational units, legal entities, recruiting data (jobs, candidates, applications), documents, reports, and webhooks. It spans 46 endpoints across the full employee lifecycle.

Can I set up webhooks for employee data changes?

Yes. POST /webhooks creates a subscription with a callback URL and event filter. GET /webhooks lists active subscriptions, PATCH /webhooks/{id} updates configuration, and DELETE /webhooks/{id} removes them. GET /webhooks/{id}/events shows the event history for a specific webhook.

Can I limit what my agent is allowed to do with the Personio API?

Yes. Because you run Jentic One yourself, your own rules decide which Personio operations and credentials the agent can use, so you can grant just what it needs, such as listing persons or creating an absence period, and leave writes like creating person records or registering webhooks out unless you add them. For reports the report id sits in the URL path (GET /reports/{id}), so a rule can pin the agent to reading a single report. For the person, absence, and attendance operations the target travels in the request body, so there you scope the agent by the specific operations it may call rather than by a fixed record.