ApiBorne
Sommaire du guide

getCheckinNotifySettings

Les conditions de notification d'accueil (« Accueil RIS ») se paramètrent dans l'admin ApiBorne. Quand ce mode est actif, votre système lit ces réglages ici — la configuration ApiBorne est la source de vérité, votre copie locale ne sert que de repli.

POST/api/kioskTicket/getCheckinNotifySettings
Auth : Authorization = clé d'autorisation compte (brute)

Pourquoi ce service existe

Les conditions de notification d'accueil (« Accueil RIS ») peuvent être portées par l'admin ApiBorne plutôt que par votre configuration. Dans ce mode, votre système doit lire les réglages qui font foi ici — sinon deux configurations divergent et l'accueil notifie (ou pas) à contretemps. Votre copie locale ne sert plus que de repli quand le serveur ApiBorne est injoignable.

Authentification : AUTH_KEY et licenceUuid

AUTH_KEY est la « Clé d'autorisation compte » : le secret partagé de l'intégration, affiché dans l'admin ApiBorne → page Connectivité (champ copiable) et remis à votre système à l'installation. C'est la même clé que celle que vous validez en X-Kiosk-Auth-Key sur les appels entrants — ici elle s'envoie dans le header Authorization, brute (sans préfixe Bearer).

Le licenceUuid vient de la même page Connectivité : c'est l'identifiant (pas un secret) qui désigne la licence cible dans le corps de chaque appel.

Provisioning : l'admin ApiBorne (page Connectivité) fournit la clé d'autorisation compte et l'UUID de licence, stockés dans la configuration de l'éditeur.Admin ApiBornepage Connectivité« Clé d'autorisation compte » 🔑« UUID de la licence »copiées UNE FOIS, à l'installationConfiguration de votre systèmeclé → header Authorization (brute)et validation de X-Kiosk-Auth-Keyuuid → corps des appels sortantsLa clé est un SECRET (authentifie) · l'UUID est un identifiant (désigne la licence)
Deux valeurs copiées une fois, à l'installation — la clé authentifie tous les flux, l'UUID désigne la licence dans les appels sortants.

Quand l'appeler

Avant d'évaluer vos conditions d'accueil (notifier ou non les équipes à l'arrivée d'un patient). La réponse contient toutes les entrées — globale (officePlaceId: null) et par lieu — la sélection lieu/globale reste faite chez vous, ainsi que les features de comportement pertinentes.

Les anomalies exclues sont transmises par code (excludedAnomalyCodes), jamais par identifiant : les ids d'anomalies sont propres à chaque référentiel — retraduisez les codes dans vos propres ids avant d'évaluer la condition.

Requête et réponse

bash
# AUTH_KEY = la clé d'autorisation compte (la même que X-Kiosk-Auth-Key), envoyée BRUTE
curl -sS "$APIBORNE/api/kioskTicket/getCheckinNotifySettings" \
  -H "Authorization: $AUTH_KEY" -H 'Content-Type: application/json' -d '{
  "licenceUuid": "ecdb8b76-…"
}'
# → 200 { "settings": [ { "officePlaceId": null, "enabled": true,
#                          "excludedAnomalyCodes": ["DM", "CE"], … } ],
#          "features": { … } }

Mise en cache

Un cache court par établissement (30 secondes est un bon ordre de grandeur) suffit : les réglages changent rarement, et le repli sur votre configuration locale couvre l'indisponibilité du serveur ApiBorne. Sur un cluster, un cache par nœud avec TTL est sûr — la donnée est en lecture seule.