The signed-in member

Your backend reads the signed-in user's own organisation membership from the Members API, for example to prefill a form with their address:

GET <studio>/api/v1/members/me
Authorization: Bearer ofk_<prefix>_<secret>
X-Frontend-User-Token: <the user's access token>

• Server to server only. Send both from your backend: your frontend's key, and the user's current access token unchanged. Refresh the token first if it has expired.
• Only for an internal frontend, with a token issued to your own client at your organisation.

Names and email do not need this call: they are in the access token (see Tokens and claims).

The answer

200 with what the Studio stored at the user's last sign-in:

{
  "status": "valid",
  "communities": ["Retirees", "All staff"],
  "register": "Retirees",
  "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" }
  }
}

A user without a membership gets status: null and only frontendsUsed. The answer never carries the member code, claims or why a membership is not valid.

Member data

memberData is read live, on each call, from the register the membership is linked to; the Studio keeps no copy. Use it to prefill, never as a record of your own.

• A value the register does not hold is null; address is null when street, zip and city all are. An external register holds no phone, so phone is always null there.
• "unavailable" when the member's external register cannot be reached or does not answer within 1.5 seconds. The rest of the answer stands: let the user fill the form by hand, or ask again later.
• null when status is not valid, or when the register no longer holds the member (the entry is gone or deactivated, or an external register does not find them).

Expect the answer within 300 ms for an internal register and 2 seconds for an external one.

A refused call

Every refusal is the same 401 {"error": "unauthenticated"}: a missing or revoked key, a disconnected or external frontend, a missing, expired or forged token, a Studio user's token, another frontend's or another organisation's token, a user without a frontend activation for your frontend, or one whose membership is deactivated. Treat it as signed out, or check your key.

The endpoint checks the token itself, not its session: after a user signs out, is blocked or resets their password, an access token already issued keeps working here until it expires, at most 1 hour. The refresh then fails.

Limits

600 requests per frontend user an hour, then 429 {"error": "rate_limited"} without Retry-After. Normal traffic never reaches it; it stops a runaway loop. 503 {"error": "unavailable"} is the Studio's own failure: retry later. A register that cannot answer is never a 503, only memberData: "unavailable".

Reference

The signed-in frontend user's membership