ApiBorne
Sommaire du guide

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.

Architecture : la borne appelle les routes de communication de l'éditeur ; le serveur ApiBorne sonde les routes de configuration et offre ses services à l'éditeur.Borne ApiBorneapplication navigateurconf chargée au démarrageVotre serveur (éditeur)Routes de communicationidentify · documents · check-in…Routes de configurationGET /config/* — référentielsServeur ApiBorneServices offertstickets · statuts · réglagesadmin + Cockpit + numérotation1 · parcours patientX-Kiosk-Auth-Key + X-Kiosk-Device-Id2 · sonde + référentielsX-Kiosk-Auth-Key seule3 · notificationsAuthorization (clé brute)configuration + réservation des tickets (au démarrage / au check-in)
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).
L'appelant est le serveur ApiBorne, jamais une borne — d'où l'authentification par la clé seule, sans X-Kiosk-Device-Id.

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.

Séquence : l'administrateur active l'intégration, le serveur ApiBorne sonde les cinq routes de configuration, puis déverrouille la configuration des bornes.Admin ApiBornepage IntégrationServeur ApiBorneconfig-checkVotre serveur/config/*1 · Enregistrer / activer l'intégrationloop — pour chacune des 5 routes2 · GET /config/… (X-Kiosk-Auth-Key)200 — forme attendue vérifiéeéchec d'une route → croix rouge, configuration verrouillée3 · Intégration validée — menus déverrouillés4 · Relectures régulières des référentielslieux/examens/praticiens/salles alimentent les écrans de l'admin
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.

Comment les appeler

  1. base : votre serveur, sous le base path du contrat /api/apiborneIntegrationService/v1 ;
  2. auth : header X-Kiosk-Auth-Key uniquement (la « Clé d'autorisation compte » de l'admin ApiBorne, page Connectivité) ;
  3. 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" } ] }

Les 6 routes

Swagger à télécharger

Les routes de configuration ont leur propre spécification OpenAPI, distincte du contrat principal (schémas de réponse, exemples, sécurité) :