Authentifizierung

Jede Anfrage trägt einen API-Schlüssel im Authorization-Header:

Authorization: Bearer lp_live_XXXXXXXX…    (Workspace-Schlüssel)
Authorization: Bearer lpp_live_XXXXXXXX…   (Partner-Schlüssel)

Schlüssel entstehen im Dashboard, werden bei der Erstellung einmal angezeigt und als SHA-256-Hash gespeichert — niemand, auch nicht der Support, kann einen verlorenen Schlüssel wiederherstellen. Einen Schlüssel zu verlieren heißt: ihn widerrufen und einen neuen anlegen.

Arten von Schlüsseln

• Workspace-Schlüssel (lp_live_…) wirken innerhalb eines Workspace: Links, Analytics, Domains, Audit-Log und Workspace-Webhooks. Angelegt von Workspace-Admins unter Einstellungen → API-Schlüssel.
• Partner-Schlüssel (lpp_live_…) wirken auf das Partnerkonto: Kunden, Tarife, Domains, Zahlungen, Auszahlungen und Partner-Webhooks. Angelegt von Partner-Admins.

Ruft ein Workspace-Schlüssel /partner/* auf (oder umgekehrt), kommt 403 forbidden zurück — die Endpunktfamilien sind strikt getrennt.

Berechtigungen

Berechtigungen werden je Schlüssel bei der Erstellung vergeben. Eine Anfrage braucht jede Berechtigung, die ihr Endpunkt verlangt; fehlt eine, antwortet 403 insufficient_scope und nennt die fehlende Berechtigung.

| Berechtigung | Erlaubt | |---|---| | links:read / links:write | Links lesen / anlegen, ändern, archivieren, löschen | | analytics:read | Übersicht, Zeitreihen, Aufschlüsselungen, Top-Links, CSV-Export — und die partnerweite Klick-Übersicht | | domains:read / domains:write | Domains lesen / verbinden und trennen | | qr:read | QR-Codes von Links rendern | | workspace:read | Workspace-Profil, Limits, Audit-Log | | webhooks:read / webhooks:write | Webhook-Endpunkte lesen / verwalten | | partner:read | Partnerprofil, Tarif und Nutzung | | clients:read / clients:write | Kunden lesen / anlegen, ändern, sperren | | plans:read / plans:write | Partnertarife lesen / verwalten | | payments:read | Zahlungsspiegel und Auszahlungen |

Das ist die vollständige Liste — fünfzehn Berechtigungen, und ein Schlüssel kann nur Namen daraus tragen. QR-Codes sind über die API nur lesbar: Einen zu rendern braucht qr:read, und eine Schreibberechtigung für QR gibt es nicht, weil es keinen verändernden QR-Endpunkt gibt.

Eine Kombination führt regelmäßig in die Irre: GET /partner/analytics/overview braucht analytics:read auf dem Partner-Schlüssel, nicht partner:read. Jeder Analytics-Endpunkt nutzt dieselbe Berechtigung, unabhängig von der Schlüsselart.

Geben Sie jeder Integration einen eigenen Schlüssel mit den minimal nötigen Berechtigungen: Ein Schlüssel für ein Dashboard-Widget kommt mit links:read + analytics:read aus, während ein Bereitstellungsskript clients:write braucht.

Abhängigkeit vom Tarif

API-Zugriff ist eine Tariffunktion (api_access):

• Bei Workspace-Schlüsseln müssen sowohl der Workspace-Tarif als auch der Plattformtarif des Partners API-Zugriff enthalten;
• bei Partner-Schlüsseln muss der Plattformtarif des Partners ihn enthalten.

Ein Tarif ohne API-Zugriff antwortet mit 403 plan_restricted. Test-Workspaces ohne Tarif sind nicht eingeschränkt.

Wechsel und Widerruf

Ein Widerruf greift sofort: Die nächste Anfrage antwortet mit 401 unauthorized. Für einen Wechsel ohne Ausfall legen Sie zuerst den neuen Schlüssel an, stellen die Integration um und widerrufen dann den alten. Jeder Schlüssel führt last_used_at, ein ungenutzter alter Schlüssel fällt vor dem Widerruf also leicht auf.

Optional kann ein Schlüssel ein Ablaufdatum tragen — abgelaufene Schlüssel verhalten sich genau wie widerrufene.

Bewährte Praxis

• Schlüssel sind Geheimnisse: Bewahren Sie sie in einem Secret-Manager auf, niemals in clientseitigem Code, in Repositorys oder in Logs.
• Ein Schlüssel je Integration — den einen zu widerrufen bricht die anderen nicht, und das Audit-Log ordnet jede Änderung dem Schlüssel zu, der sie vorgenommen hat.