Den Menschen hinter einem Schreibvorgang benennen

Den Menschen hinter einem Schreibvorgang benennen#

Dein Token ist ein Maschinentoken — es hat keinen sub-Claim, die API kann also nicht ermitteln, wer für eine Änderung verantwortlich ist. Datensätze, die eine Person ausweisen müssen, verlangen darum, dass du eine nennst, im Body-Feld authorizing_manager.

POST /api/public/v1/shifts/ HTTP/1.1
Host: app.shiftavo.com
Authorization: Bearer <access_token>
Content-Type: application/json

{
  "location": "0194d1c0-…",
  "position": "0194d1c0-…",
  "start_date": "2026-08-01T09:00:00Z",
  "end_date": "2026-08-01T17:00:00Z",
  "authorizing_manager": "0194d1c0-…"
}

Die Regeln#

  • Pflicht bei jedem Schreibvorgang auf shifts — anlegen, PATCH, publish, unpublish, cancel, zuteilen, Zuteilung aufheben — und bei POST /events/. Fehlt es, gibt es einen 400, der das Feld nennt.

  • Der Wert ist eine Mitarbeitenden-ID aus GET /employees/, derselbe ID-Raum, den auch der Rest der Schnittstelle nutzt.

  • Es muss ein Mitglied mit Führungsrolle sein — Owner, Admin oder Manager — in deinem Unternehmen. Alles andere ergibt einen 400.

  • Sie wird als Ersteller oder Zuteiler des Datensatzes vermerkt und erscheint im Änderungsprotokoll.

Du musst nie raten, welche Schreibvorgänge es brauchen: Der Eintrag jeder Operation in der API-Referenz nennt das Feld.

Einen Wert wählen#

Die meisten Anbindungen bestimmen einen Service-Manager — die Person, die für das Tun der Anbindung geradesteht — und senden deren ID bei jedem Schreibvorgang. Weiss dein Quellsystem bereits, welcher Manager eine Änderung freigegeben hat, übergib diese Person; dann ist das Änderungsprotokoll wirklich nützlich statt einheitlich zugeordnet.

Die ID muss gültig bleiben. Verlässt diese Person das Unternehmen und wird ausgetragen, schlagen Schreibvorgänge mit einem 400 fehl, bis du auf jemand anderen zeigst — nimm also lieber ein Konto, das einzelne Personalwechsel überdauert.