Hello, We integrated four data services against the sandbox: hr:exchange, hr:exports, accounting:extf-files, and hr:documents. Three work. hr:documents responds with a 401 error on every endpoint—apparently not from the API gateway, but from the backend behind it. Vicinity * Product: hr:documents (DATEV Data Service Documents Human Resources), Version 1 * Base URL: https://hr-documents.api.datev.de/platform-sandbox/v1 * Sandbox Client: 455148-1, Sandbox User: Test6 * Scope requested and confirmed in the consent dialog: datev:hr:documents:upload (displayed as "Upload of documents for DATEV Personnel File") * Header: Authorization: Bearer <opaque Token>, X-Datev-Client-Id: <client_id>, Accept: */* Symptom — all hr:documents endpoints GET /clients, GET /clients/455148-1, POST /clients/{consultant number-client number}/documents/upload, POST /clients/{client_guid}/documents answers identical: HTTP/1.1 401 Unauthorized Server: Apache Content-Type: text/xml WWW-Authenticate: Basic realm="Realm", charset="UTF-8" Content-Language: de (body empty) Cross-check — same token, same header, same client, same second GET https://hr-exports.api.datev.de/platform-sandbox/v1/clients/455148-1 -> 200 GET https://hr-exchange.api.datev.de/platform-sandbox/v1/clients/455148-1 -> 200 Why we are ruling out the gateway as the cause The gateway errors all look different (each application/problem+json): | Test Case | Gateway Response | |---|---| | Invalid Token | 401, WWW Authenticate: Bearer error='invalid_token', "access token invalid, revoked or missing required scope" | | X-Datev Client ID missing or incorrect | 401, "Invalid client id or secret." | | Product subscribed, but scope not requested (tested with accounting:clients) | 401, "Cannot pass the security checks that are required by the target API or operation" | | Unknown Path | 404, "No resources match requested URI" | | GET/DELETE on /documents | 405, "The method is not allowed for the requested URL" | None of these scenarios occur with hr:documents: The request passes through the gateway and is answered by the server, Apache, with a Basic Realm Challenge . Therefore, from our perspective, the token, scope, and routing are all correct. GET /clients also fails — this call has no parameters, no file, and no client GUID. Therefore, multipart structure, file type, file size, or the choice between GUID and consultant number endpoints cannot be the cause. Tested with two apps, one of which is demonstrably subscribed to hr:documents (version 1, simple plan) — identical behavior. Tokens are always fresh, even immediately after a refresh. x-global-transaction-id (07/30/2026) 17:48:45 GMT 401 b79902aa6a6b8e7d35f33691 GET /v1/clients 17:48:46 GMT 401 b79902aa6a6b8e7e276397a9 GET /v1/clients/455148-1 17:48:46 GMT 401 b79902aa6a6b8e7e35f339f1 POST /v1/clients/455148-1/documents/upload 17:48:46 GMT 401 b79902aa6a6b8e7e32cbd96d POST /v1/clients/455148-1/documents 17:48:47 GMT 200 e1227d436a6b8e7f33492a83 GET hr-exports /v1/clients/455148-1 (countercheck) Questions 1. What additional checks does the hr:documents backend perform besides gateway authentication when it responds with "Basic realm="Realm"? 2. Does the DATEV personnel file or "Personnel Management Documents" need to be separately activated for the sandbox client 455148-1 / user Test6 ? 3. Is the hr:documents sandbox generally usable, or does it need to be activated per app or per client? 4. If activation is missing: how is it requested? App ID and other transaction IDs can be provided via private message. Thank you!
... Mehr anzeigen
