Authentifizierung

Bearer-Keys

Jede authentifizierte Anfrage trägt einen Authorization-Header mit deinem lps_-Key:

Authorization: Bearer lps_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Keys werden im Dashboard unter Konto → Entwickler erstellt und widerrufen. Sie werden gehasht gespeichert (SHA-256); nach dem Erstellen wird nur ein kurzer Präfix angezeigt, bewahre den vollständigen Wert also sicher auf. Ein widerrufener Key gilt sofort nicht mehr.

Ein Key = ein Profil

Ein Key ist an genau ein Mitglied gebunden — ein LinkedIn-Profil. Wer den Key in seinem eigenen Login erstellt, bestimmt, welches Profil er steuert. Es gibt keine Multi-Profil- oder „Service“-Keys: Jeder Kunde verbindet genau ein Profil und nutzt dafür einen Key.

Mit GET /me prüfst du, zu welchem Profil ein Key gehört:

curl https://app.tidefall.de/api/v1/me \
  -H "Authorization: Bearer lps_YOUR_KEY"

Trennung zwischen Mitgliedern

Die Identität stammt ausschließlich aus dem Key — nie aus Request-Body, Query-String oder URL. Auch wenn zwei Mitglieder zur selben Organisation gehören, kann der Key des einen die Posts oder Ideen des anderen weder lesen, bearbeiten, planen, veröffentlichen noch dessen Analysen sehen.

Wer eine Ressource anfragt, die existiert, aber jemand anderem gehört, bekommt dieselbe Antwort wie bei einer nicht existierenden — ein neutrales 404 not_found. Die API bestätigt nie die Existenz fremder Ressourcen und liefert kein 403, das sie verraten würde.

{
  "error": {
    "code": "not_found",
    "message": "Post not found"
  }
}

Nicht authentifizierte und öffentliche Endpunkte

Ein fehlender, fehlerhafter, widerrufener oder inaktiver Key liefert 401 unauthorized. Zwei Endpunkte brauchen keinen Key:

• GET /api/v1/health — Erreichbarkeitsprüfung.
• GET /api/v1/openapi.json — das OpenAPI-Dokument.