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 shifts write — create, PATCH, publish, unpublish, cancel, assign, unassign — and on POST /events/. Omitting it is a 400 that names the field.

  • 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.

  • 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 leaves and is offboarded, writes start failing with a 400 until you point at someone else, so prefer an account that outlives individual staff changes.