canonical: https://jentic.com/apis/personio.de/personio-authentication # Personio De Authentication The Personio Authentication API provides a single endpoint for obtaining access tokens to use with the Personio Personnel API. It accepts client credentials (client_id and client_secret) and returns a Bearer token that authenticates subsequent requests to Personio's HR management endpoints. This is the gateway to all Personio API operations. ## For AI agents Obtain Bearer access tokens for the Personio HR platform by submitting client credentials. This single-endpoint API is the authentication gateway for all Personio API operations. ## Scope Does not handle employee data, absences, attendance, or any HR operations - use for token acquisition only. ## Capabilities - Generate Bearer tokens from client_id and client_secret credentials - Authenticate API requests to the Personio HR management platform - Support token-based access control for downstream HR data endpoints - Enable credential exchange for machine-to-machine API access ## Use cases ### Machine-to-Machine Authentication Obtain a Bearer token for automated systems that need to access Personio HR data without user interaction. The POST /auth endpoint accepts client_id and client_secret parameters and returns a token that can be used as a Bearer header on all Personio Personnel API requests. This enables scheduled sync jobs, reporting pipelines, and agent-driven HR operations. Example prompt: Submit client_id and client_secret to POST /auth and extract the Bearer token from the response for use in subsequent Personio API calls ### Token Acquisition for HR Data Pipelines Integrate Personio authentication into data pipelines that periodically sync employee records, absence data, or attendance information. The token obtained from POST /auth is required before any personnel data can be accessed. Agents handle token acquisition as the first step in any Personio data retrieval workflow. Example prompt: Call POST /auth with stored credentials, verify the response contains a valid token field, and cache it for use across multiple Personio Personnel API requests ### AI Agent Personio Authentication via Jentic AI agents authenticate with Personio through Jentic without directly handling client secrets. Jentic's credential vault stores the client_id and client_secret, performs the token exchange via POST /auth, and provides the resulting Bearer token to the agent. This eliminates credential exposure in agent contexts and simplifies multi-step HR operation workflows. Example prompt: Search Jentic for 'authenticate with Personio', load the POST /auth operation schema, and execute with credentials from the vault to receive a Bearer token ## Key endpoints | Method | Path | Description | | --- | --- | --- | | POST | /auth | Exchange client credentials for a Bearer token | ## Key resources - **Auth** — Exchange client credentials for a Bearer access token ## Why Jentic - **Setup:** Wiring Personio's Authentication endpoint by hand means posting to /auth on api.personio.de to obtain a token before any HR call, then threading that token through downstream requests yourself. Through Jentic you install once, import the Personio Authentication API from the API Directory, store the credential once, and your agent calls it. - **Permission scoping:** This API exposes only POST /auth for token acquisition, so the honest control is operations-only: you limit the agent to the single auth operation it needs, and no employee or HR data operation is reachable here because none is exposed. - **Credential handling:** Your Personio client credentials are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'obtain a Personio access token', and Jentic returns the matching auth operation with its input schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **Personio API** — The Personio API provides the full HR data surface (employees, absences, attendance) that requires tokens from this auth endpoint. - **Auth0 API** — Auth0 provides a full identity platform with SSO, MFA, and user management beyond simple token exchange. - **Okta API** — Okta offers enterprise identity management with directory services, SSO, and adaptive MFA. ## FAQ ### What authentication does the Personio Authentication API use? The POST /auth endpoint itself requires no pre-existing authentication. It accepts client_id and client_secret as request body parameters and returns a Bearer token. This token is then used in the Authorization header for all subsequent Personio Personnel API requests. ### How long are Personio access tokens valid? The OpenAPI spec does not specify an explicit token TTL. In practice, tokens should be refreshed before making critical API calls. Implement token caching with a conservative expiry assumption and re-authenticate when receiving HTTP 401 responses. ### Can I use the same token across multiple Personio API endpoints? Yes. The Bearer token returned by POST /auth authenticates requests to all Personio Personnel API v2 endpoints including persons, absences, attendance, projects, compensations, and recruiting. One token covers the entire HR data surface. ### How do I authenticate with Personio through Jentic? Search Jentic for 'get Personio access token' to discover the POST /auth operation. Jentic stores your client_id and client_secret in its encrypted vault and handles the token exchange automatically, so the raw credentials never enter the agent's context. Get started with Jentic One, the self-hosted execution layer. ### What happens if authentication fails? POST /auth returns an error response with details about the failure. Common causes include invalid client_id, expired client_secret, or incorrect credential formatting. The response body contains an error message indicating the specific issue. ### Can I limit what my agent is allowed to do with the Personio Authentication API? Yes. Because you run Jentic One yourself, your own rules decide which operations and credentials the agent may use, and this API exposes only the POST /auth token-exchange operation, so you scope the agent to that single call and nothing else. No employee, absence, or attendance data is reachable through this API, since none of those operations exist here. Your client_id and client_secret stay stored on your own instance and are injected only when the agent runs the auth call.