Nommer la personne derrière une écriture

Nommer la personne derrière une écriture#

Ton jeton est un jeton machine — il n’a pas de claim sub, donc l’API ne peut pas déterminer qui est responsable d’un changement. Les enregistrements qui doivent attribuer une personne t’obligent donc à en nommer une, dans un champ de corps 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-…"
}

Les règles#

  • Obligatoire sur toute écriture shifts — création, PATCH, publish, unpublish, cancel, assignation, désassignation — et sur POST /events/. L’omettre donne un 400 qui nomme le champ.

  • La valeur est un id de collaborateur issu de GET /employees/, le même espace d’ids que le reste de la surface.

  • Ce doit être un membre de la direction — Propriétaire, Administrateur ou Manager — de ton entreprise. Tout autre cas donne un 400.

  • Cette personne est inscrite comme créatrice ou assignatrice de l’enregistrement et apparaît dans la piste d’audit.

Tu n’as jamais à deviner quelles écritures en ont besoin : l’entrée de chaque opération dans la référence de l’API indique le champ.

Choisir une valeur#

La plupart des intégrations désignent un manager de service — la personne responsable de ce que fait l’intégration — et envoient cet id sur chaque écriture. Si ton système source sait déjà quel manager a approuvé un changement, transmets plutôt cette personne ; la piste d’audit devient alors réellement utile au lieu d’être attribuée uniformément.

L’id doit rester valide. Si cette personne quitte l’entreprise et que son départ est enregistré, les écritures commencent à échouer avec un 400 jusqu’à ce que tu pointes vers quelqu’un d’autre ; privilégie donc un compte qui survit aux changements de personnel.