Das angemeldete Mitglied

Ihr Backend liest die eigene Organisationsmitgliedschaft des angemeldeten Benutzers aus der Mitglieder-API, etwa um ein Formular mit seiner Anschrift vorauszufüllen:

GET <studio>/api/v1/members/me
Authorization: Bearer ofk_<Präfix>_<Geheimnis>
X-Frontend-User-Token: <das Zugriffstoken des Benutzers>

• Nur von Server zu Server. Senden Sie beides aus Ihrem Backend: den Schlüssel Ihres Frontends und das aktuelle Zugriffstoken des Benutzers, unverändert. Erneuern Sie das Token zuerst, wenn es abgelaufen ist.
• Nur für ein internes Frontend, mit einem Token, das für Ihren eigenen Client bei Ihrer Organisation ausgestellt wurde.

Namen und E-Mail-Adresse brauchen diesen Aufruf nicht: Sie stehen im Zugriffstoken (siehe Tokens und Claims).

Die Antwort

200 mit dem, was das Studio bei der letzten Anmeldung des Benutzers gespeichert hat:

{
  "status": "valid",
  "communities": ["Pensionistinnen und Pensionisten", "Gesamte Belegschaft"],
  "register": "Pensionistinnen und Pensionisten",
  "lastVerifiedAt": "2026-10-24T08:15:00.000Z",
  "frontendsUsed": [
    {
      "name": "Pannoniqa Portal",
      "firstActivatedAt": "2026-09-01T07:30:00.000Z",
      "lastSignedInAt": "2026-10-24T08:15:00.000Z"
    }
  ],
  "memberData": {
    "birthDate": "1958-03-14",
    "phone": "+43 660 1234567",
    "address": { "street": "Beispielgasse 12", "zip": "7000", "city": "Eisenstadt" }
  }
}

Ein Benutzer ohne Mitgliedschaft erhält status: null und nur frontendsUsed. Die Antwort enthält nie die Mitgliedsnummer, Claims oder den Grund, warum eine Mitgliedschaft nicht gültig ist.

Die Namen in diesem Beispiel sind die Register- und Community-Namen, wie die Organisation sie im Studio angelegt hat; das Studio übersetzt sie nicht.

Mitgliedsdaten

memberData wird bei jedem Aufruf live aus dem Register gelesen, mit dem die Mitgliedschaft verknüpft ist; das Studio behält keine Kopie. Verwenden Sie die Daten zum Vorausfüllen, nie als eigenen Datensatz.

• Ein Wert, den das Register nicht führt, ist null; address ist null, wenn Straße, Postleitzahl und Ort alle fehlen. Ein externes Register führt keine Telefonnummer, daher ist phone dort immer null.
• "unavailable", wenn das externe Register des Mitglieds nicht erreichbar ist oder nicht innerhalb von 1,5 Sekunden antwortet. Der Rest der Antwort gilt: Lassen Sie den Benutzer das Formular von Hand ausfüllen oder fragen Sie später erneut.
• null, wenn status nicht valid ist oder das Register das Mitglied nicht mehr führt (der Eintrag ist weg oder deaktiviert, oder ein externes Register findet es nicht).

Rechnen Sie mit einer Antwort innerhalb von 300 ms bei einem internen Register und 2 Sekunden bei einem externen.

Ein abgewiesener Aufruf

Jede Abweisung ist dasselbe 401 {"error": "unauthenticated"}: ein fehlender oder widerrufener Schlüssel, ein getrenntes oder externes Frontend, ein fehlendes, abgelaufenes oder gefälschtes Token, das Token eines Studio-Benutzers, das Token eines anderen Frontends oder einer anderen Organisation, ein Benutzer ohne Frontend-Aktivierung für Ihr Frontend oder einer, dessen Mitgliedschaft deaktiviert ist. Behandeln Sie es als Abmeldung oder prüfen Sie Ihren Schlüssel.

Der Endpunkt prüft das Token selbst, nicht seine Sitzung: Nachdem sich ein Benutzer abgemeldet hat, gesperrt wurde oder sein Passwort zurückgesetzt hat, funktioniert ein bereits ausgestelltes Zugriffstoken hier weiter, bis es abläuft, höchstens 1 Stunde. Der Refresh schlägt dann fehl.

Limits

600 Anfragen pro Frontend-Benutzer und Stunde, danach 429 {"error": "rate_limited"} ohne Retry-After. Normaler Verkehr erreicht das nie; es stoppt eine außer Kontrolle geratene Schleife. 503 {"error": "unavailable"} ist ein Ausfall des Studios selbst: Versuchen Sie es später erneut. Ein Register, das nicht antworten kann, ist nie eine 503, nur memberData: "unavailable".

Referenz

Die Mitgliedschaft des angemeldeten Frontend-Benutzers