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

```http
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 <a href="../../api/index.html">API Reference</a> 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.

## Related

There is one more place the "a machine can't be accountable" rule shows up: if a company uses two-step time approval, the API must name the manager responsible for an approval, and it cannot switch the company out of that mode. That setting is deliberately admin-only, in the browser.