Naming the human behind a write

Naming the human behind a write#

Your token is a machine token — it has no sub claim, so the API cannot work out who is accountable for a change. Records that must attribute a person therefore make you name one, in an authorizing_manager body field.

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-…"
}

The rules#

  • Required on every non-delete shifts write — create, PATCH, publish, unpublish, cancel, assign — and on POST /events/. Omitting it is a 400 that names the field. The deletes (including unassign) don’t require it — a DELETE never takes a body.

  • The value is an employee id from GET /employees/, the same id space the rest of the surface uses.

  • It must be a management member — Owner, Admin, or Manager — of your company. Anything else is a 400.

  • If you name one on a leave decision (confirm/, decline/, revoke/) or on a timesheet approve/ or unapprove/, that person also needs the permission for the action. For leave, the requester must be within their role’s data scope, and they can decide their own leave only if their role covers the whole company. Otherwise the call is a 403.

  • It is stamped as the record’s creator or assigner and appears in the audit trail.

You never have to guess which writes need it: each operation’s entry in the API Reference lists the field.

Picking a value#

Most integrations designate one service manager — the person accountable for what the integration does — and send that id on every write. If your source system already knows which manager approved a change, pass that person instead; the audit trail is then genuinely useful rather than uniformly attributed.

The id must stay valid. If that person’s role is demoted below management — or they leave the company entirely — writes start failing with a 400 until you point at someone else, so prefer an account that outlives individual staff changes.