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 hors suppression — création, PATCH, publish, unpublish, cancel, assignation — et sur POST /events/. L’omettre donne un 400 qui nomme le champ. Les suppressions (y compris la désassignation) ne l’exigent pas — un DELETE ne prend jamais de corps.

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

  • Si tu en nommes un sur une décision d’absence (confirm/, decline/, revoke/) ou sur un approve/ ou unapprove/ de feuille de temps, cette personne a aussi besoin de l’autorisation correspondant à l’action. Pour une absence, le demandeur doit se trouver dans la portée des données du rôle de cette personne, et celle-ci ne peut décider de sa propre absence que si son rôle couvre toute l’entreprise. Sinon, l’appel donne un 403.

  • 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 le rôle de cette personne est rétrogradé en dessous de la direction — ou si elle quitte complètement l’entreprise — 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.