ApiBorne
Sommaire du guide

RDV par identifiant

Même réponse que by-code (patient + appointment + otherAppointments), mais par identifiant déjà connu : rechargement après un PATCH patient, mode simulation, et re-vérification par le serveur ApiBorne.

GET/appointments/{appointmentId}
Base : {editorBaseUrl}/api/apiborneIntegrationService/v1Auth : X-Kiosk-Auth-Key + X-Kiosk-Device-IdRoute obligatoire

Pourquoi cette route existe

La borne et le serveur ApiBorne ont régulièrement besoin de recharger un RDV qu'ils connaissent déjà : après une modification patient (le PATCH répond 204 sans corps), au retour d'un écran, ou côté serveur pour re-vérifier un ticket affiché au Cockpit. Cette route est la source canonique de l'état d'un RDV — même forme de réponse que by-code, sans repasser par une recherche.

Sémantique

La borne appelle cette route pour obtenir les données canoniques après une modification (PATCH /patients répond 204 sans corps, le rechargement se fait ici). L'identifiant est celui que vous avez renvoyé dans une réponse précédente — opaque et stable pendant tout le parcours.

Requête

bash
curl -sS "$BASE/appointments/apt-1001" "${AUTH[@]}"

Points d'attention

Le serveur ApiBorne utilise aussi cette route pour re-vérifier les tickets affichés au Cockpit (réconciliation) : renvoyez un status et un startDate exacts — un RDV annulé chez vous disparaît ainsi automatiquement du Cockpit.

Implémentation de référence