Connexion du personnel

Le personnel d'accueil se connecte au Cockpit ApiBorne avec ses identifiants habituels — les vôtres. L'appel vient du serveur ApiBorne, pas d'une borne.

POST/staff/sign-in

Base : {editorBaseUrl}/api/apiborneIntegrationService/v1Auth : X-Kiosk-Auth-Key seuleRoute obligatoire

Pourquoi cette route existe

Le Cockpit ApiBorne (suivi des arrivées, appel des patients) est utilisé par votre personnel d'accueil : plutôt que de gérer un annuaire de comptes en double, ApiBorne délègue l'authentification à l'éditeur. Les agents gardent leurs identifiants habituels, et vous gardez la main sur les droits — quels établissements pour quel agent. Route obligatoire — sans comptes personnel chez vous, l'implémentation minimale conforme répond systématiquement 401 INVALID_CREDENTIALS.

Sémantique

Identifiants invalides → 401 INVALID_CREDENTIALS ;
identifiants valides → 200 avec les établissements accessibles à l'utilisateur (module borne actif, filtrés sur la clé appelante). ApiBorne rapproche officeId/officeVisibleId de sa configuration locale pour résoudre la licence et ouvrir la session ;
userEmail est la clé stable des préférences par utilisateur côté ApiBorne (affectation de guichet…).

Requête et réponse

bash

curl -sS "$BASE/staff/sign-in" -H "X-Kiosk-Auth-Key: $KEY" -H 'Content-Type: application/json' -d '{
  "login": "accueil@clinique.fr",
  "password": "********"
}'
# → 200 { "offices": [ { "officeId": "42", "officeVisibleId": "CLN", "name": "Clinique du Parc" } ],
#          "userEmail": "accueil@clinique.fr", "userDisplayName": "Marie DURAND" }

Seul X-Kiosk-Auth-Key est requis — pas de device id, comme PUT /appointments/{id}/status.

Implémentation de référence

src/app/api/apiborneIntegrationService/v1/staff/sign-in/route.ts → — comptes de démonstration en clair (un vrai éditeur hache ses mots de passe).