Benutzer abrufen

Gibt eine paginierte Liste aller Benutzer zurück.

Request

GET /api/oauth/v2/resource/users

Header

Header	Wert
Authorization	Bearer {access_token}

Query-Parameter

Parameter	Typ	Pflicht	Beschreibung
offset	integer	Nein	Startposition (Standard: 0)
limit	integer	Nein	Anzahl Ergebnisse (Standard: 50, Max: 200)
view	string	Nein	Antwortformat: default (Vorgabe) oder slim (schlanker Abruf)
createdSince	string (ISO 8601)	Nein	Nur Benutzer, die ab diesem Zeitpunkt angelegt wurden (createdAt >=)
createdUntil	string (ISO 8601)	Nein	Nur Benutzer, die bis zu diesem Zeitpunkt angelegt wurden (createdAt <=)
updatedSince	string (ISO 8601)	Nein	Nur Benutzer, die ab diesem Zeitpunkt geändert wurden (updatedAt >=). Neu angelegte Benutzer kommen mit, weil der Änderungszeitpunkt beim Anlegen gesetzt wird.
updatedUntil	string (ISO 8601)	Nein	Nur Benutzer, die bis zu diesem Zeitpunkt geändert wurden (updatedAt <=)

Erforderlicher Scope: users

Hinweis: Für einen Abgleich genügt updatedSince – der Wert deckt neue und geänderte Benutzer ab.

Hinweis: Formate, Zeitzonen-Verhalten, Sortierung im Filter-Modus, Cursor-Strategie und die meta.total-Falle gelten für alle Zeitstempel-Filter gleich – siehe Inkrementeller Abgleich.

Hinweis zu gelöschten Benutzern: Benutzer führen keinen Löschzeitpunkt. Deshalb gibt es hier kein deletedSince – gelöschte Benutzer sind über die API nicht ermittelbar. Der Endpoint liefert sie weiterhin aus, ohne sie zu kennzeichnen.

Im updatedSince-Feed erscheint eine Löschung wie eine gewöhnliche Änderung. Rechne beim Abgleich über Benutzer also nicht mit einer Löscherkennung.

Hinweis zu Benutzern ohne Änderungszeitpunkt: Bei manchen Benutzern ist updatedAt leer. Das betrifft Altbestand aus der Zeit vor der automatischen Zeitstempelung sowie Massenimporte. updatedSince liefert solche Benutzer nicht – auch nicht mit einem sehr frühen Datum.

Hol dir für den Erstabgleich deshalb einmal den Vollbestand ohne Zeitstempel-Filter. Danach arbeitest du inkrementell mit updatedSince weiter.

Response

Erfolg (200 OK)

{
  "data": [
    {
      "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
      "title": "Dr.",
      "firstName": "Maria",
      "lastName": "Muster",
      "abbreviation": "MM",
      "sex": 1,
      "email": "maria.muster@example.com",
      "color": "#74AFAD",
      "isDoctor": true,
      "showBookingWeeks": 6,
      "sort": 0,
      "isBookable": true,
      "tenancies": [
        {
          "id": "f0e1d2c3-b4a5-6789-fedc-ba9876543210",
          "name": "Ordination Muster",
          "abbreviation": "OM",
          "color": "#00adba"
        }
      ],
      "createdAt": "2026-01-15T08:00:00+01:00",
      "updatedAt": "2026-06-10T16:20:00+02:00"
    }
  ],
  "meta": {
    "total": 5,
    "offset": 0,
    "limit": 50
  }
}

Response-Felder

Feld	Typ	Beschreibung
data	Array	Liste der Benutzer
data[].id	string (UUID)	Eindeutige Benutzer-ID
data[].title	string | null	Akademischer Titel (z.B. Dr.)
data[].firstName	string	Vorname
data[].lastName	string	Nachname
data[].abbreviation	string | null	Kürzel des Benutzers
data[].sex	integer | null	Geschlecht (0 = männlich, 1 = weiblich)
data[].email	string | null	E-Mail-Adresse
data[].color	string	Farbe als Hex-Code (z.B. #74AFAD)
data[].isDoctor	boolean	Ob der Benutzer ein Arzt ist
data[].showBookingWeeks	integer	Wie viele Wochen im Voraus buchbar
data[].sort	integer	Sortierreihenfolge
data[].isBookable	boolean	Ob der Benutzer buchbar ist
data[].tenancies	Array	Zugeordnete Mandanten
data[].tenancies[].id	string (UUID)	Mandanten-ID
data[].tenancies[].name	string	Name des Mandanten
data[].tenancies[].abbreviation	string	Kürzel
data[].tenancies[].color	string	Farbe als Hex-Code
data[].createdAt	string (ISO 8601) | null	Erstellungszeitpunkt
data[].updatedAt	string (ISO 8601) | null	Letzter Änderungszeitpunkt
meta.total	integer	Gesamtanzahl der Benutzer
meta.offset	integer	Aktuelle Startposition
meta.limit	integer	Anzahl der zurückgegebenen Einträge

Hinweis: Die id wird als UUID zurückgegeben und wird für die Abfrage freier Slots und die Terminbuchung benötigt.

Schlanker Abruf (?view=slim)

Mit view=slim liefert der Endpoint eine schlanke Payload mit weniger Daten pro Benutzer. Ohne den Parameter bleibt der Abruf unverändert.

Wird view mehrfach angegeben, gilt die letzte Angabe – ?view=default&view=slim liefert also die schlanke Antwort.

Die schlanke Payload enthält:

id, title, firstName, lastName, abbreviation, isDoctor, createdAt, updatedAt

sex, email, color, sort, isBookable, showBookingWeeks und tenancies entfallen.

Hinweis: createdAt und updatedAt liefert derzeit zusätzlich der schlanke Abruf – der Standardabruf führt diese Felder noch nicht.

Beispiel: view=slim

{
  "data": [
    {
      "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
      "title": "Dr.",
      "firstName": "Maria",
      "lastName": "Muster",
      "abbreviation": "MM",
      "isDoctor": true,
      "createdAt": "2026-01-10T08:30:00+01:00",
      "updatedAt": "2026-05-02T11:45:00+02:00"
    }
  ],
  "meta": {
    "total": 5,
    "offset": 0,
    "limit": 50
  }
}

Beispiele

bash

curl -X GET "https://my.offisy.at/api/oauth/v2/resource/users?offset=0&limit=50&view=default&createdSince=beispiel&createdUntil=beispiel&updatedSince=2026-04-15T10%3A00%3A00&updatedUntil=2026-04-15T10%3A00%3A00" \
  -H "Authorization: Bearer {access_token}"

Server

Client-ID

Client-Secret

Parameter

offset integer

limit integer

view string

createdSince string

createdUntil string

updatedSince string

updatedUntil string

Zuerst Token anfordern

Mögliche Fehler

Status	Code	Beschreibung
400	validation_error	Ungültiger Wert für view (gültige Werte: default, slim)
400	validation_error	Ein Zeitstempel-Filter enthält einen ungültigen Wert
401	invalid_client	Ungültiger oder fehlender Access Token
403	insufficient_scope	Scope users nicht vorhanden