Authentication
Authentifizierungs-Konzept der DPP-API – API-Key-Header, Fehlercodes und Sicherheitshinweise.
Die DPP-API verwendet API-Key-Authentifizierung über einen eigenen Request-Header. Jeder API-Aufruf muss einen
gültigen API Key im x-api-key-Header enthalten.
Endpoint-Details, Beispiel-Requests und „Try it out" findest du in der interaktiven
API-Referenz (Swagger). Diese Seite beschreibt das
Konzept und die Sicherheitsanforderungen – nicht die einzelnen Endpoints.
Server
Alle API-Aufrufe gehen gegen:
https://my.digital-product-passport.cloud
Request-Header
Jeder Request übergibt den API Key im x-api-key-Header:
x-api-key: <API-KEY>
Content-Type: application/json
Beispiel mit cURL:
curl -X GET \
https://my.digital-product-passport.cloud/<endpoint> \
-H "x-api-key: <API-KEY>" \
-H "Content-Type: application/json"
API Keys werden über die Admin-Oberfläche unter Organization → API Keys erstellt und verwaltet.
Typische Fehlercodes
| HTTP Status | Bedeutung |
|---|---|
401 Unauthorized | Kein x-api-key gesetzt, Key ungültig, abgelaufen oder gesperrt |
403 Forbidden | API Key hat nicht die erforderliche Rolle für den Endpoint |
429 Too Many Requests | Rate Limit überschritten |
Die konkreten Response-Schemata pro Endpoint findest du in der Swagger-Referenz.
Sicherheitshinweise
- Übertrage API Keys ausschließlich über HTTPS.
- Verwende API Keys nie im Frontend-Code oder in öffentlichen Repositories – sie sind serverseitige Credentials.
- Speichere Keys in Umgebungsvariablen oder einem Secret Manager (z.B. Azure Key Vault, AWS Secrets Manager, HashiCorp Vault, 1Password Secrets).
- Pro Integration ein eigener Key – das erleichtert das Rotieren und die Nachvollziehbarkeit in den Audit-Logs.
- Bei Verdacht auf Kompromittierung: Key sofort über die Admin-Oberfläche deaktivieren und einen neuen ausstellen.
Weiterführend
- Organization → API Keys – Keys anlegen, rotieren und löschen
- API-Referenz (Swagger) – alle Endpoints, Parameter und Response-Schemata