Routes de configuration

Cinq GET en lecture seule qui exposent vos référentiels — lieux, types d'examens, examens, praticiens, salles — au serveur ApiBorne. Simples à implémenter, elles conditionnent tout le paramétrage des bornes.

Pourquoi ces routes

L'admin ApiBorne configure les bornes en fonction de vos données : rattacher une borne à un lieu, définir les préfixes de tickets par type d'examen, cibler un message patient sur un examen, un praticien ou une salle. Sans vos référentiels, rien de tout cela n'est paramétrable — et surtout, les identifiants doivent être les mêmes que ceux portés par vos rendez-vous sur les routes de communication (locationId, examId, examTypeId, practitionerId, roomId) : c'est ce qui permet à la borne de faire correspondre un RDV aux règles configurées.

Les trois familles de routes : la borne parle à l'éditeur (communication), le serveur ApiBorne lit les référentiels de l'éditeur (configuration) et lui offre ses services (tickets, statuts, réglages). Selon la connectivité de la licence, le parcours (1) peut aussi transiter par le relais chiffré du serveur ApiBorne, et les référentiels (2) être remplacés par un JSON statique.

L'appelant est le serveur ApiBorne, jamais une borne — d'où l'authentification par la clé seule, sans X-Kiosk-Device-Id. Alternative : si la licence est configurée en référentiels JSON statiques (un JSON uploadé dans l'admin remplace ces routes), elles ne sont jamais appelées et peuvent ne pas être implémentées — voir le guide Modes de connectivité.

La sonde de validation (config-check)

À l'activation de l'intégration, le serveur ApiBorne sonde les cinq routes de référentiels (lieux, types d'examens, examens, praticiens, salles) : il vérifie qu'elles répondent et que la forme est correcte. Tant qu'une route échoue, la configuration des bornes reste verrouillée dans l'admin (croix rouge sur la page Intégration). Implémentez-les en premier : elles débloquent tout le reste. La sixième route, /config/document-types, est recommandée mais hors sonde.

Cas particulier : en source référentiels JSON statiques, aucune sonde HTTP — chaque référentiel est validé par la présence de sa section dans le JSON uploadé (section absente = liste vide). Détails dans le guide Modes de connectivité.

La sonde (config-check) : tant que les cinq routes ne répondent pas correctement, la configuration des bornes reste verrouillée dans l'admin ApiBorne. En source « référentiels JSON statiques », pas de sonde HTTP : chaque référentiel est validé par la présence de sa section dans le JSON.

Comment les appeler

base : votre serveur, sous le base path du contrat /api/apiborneIntegrationService/v1 ;
auth : header X-Kiosk-Auth-Key uniquement (la « Clé d'autorisation compte » de l'admin ApiBorne, page Connectivité) ;
réponse : 200 avec l'enveloppe attendue — listes vides acceptées.

bash

curl -sS "https://ris.example.com/api/apiborneIntegrationService/v1/config/exam-types" \
  -H 'X-Kiosk-Auth-Key: s3cr3t-key'
# → 200 { "examTypes": [ { "id": "2", "name": "SCANNER", "ticketPrefix": "SC" } ] }