RDV par ticket (app Pass)

Le point d'entrée de l'app patient « Pass » en saisie manuelle : le patient tape le numéro imprimé sur son ticket et sa date de naissance — vous résolvez le RDV du jour correspondant.

POST/appointments/by-ticket

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

Pourquoi cette route existe

Après son passage borne, le patient repart avec un ticket imprimé. L'app « Pass » lui permet de suivre son dossier depuis son téléphone : quand il n'a pas scanné de QR, il saisit le numéro de son ticket et sa date de naissance — cette dernière sert de garde d'accès (le numéro seul, court et séquentiel, ne suffit pas à protéger un dossier). Pas de tickets exposés chez vous ? La route reste obligatoire — répondez systématiquement 404 UNKNOWN_APPOINTMENT.

Sémantique

Corps : ticketNumber, birthDate et officePlaceVisibleId requis (+ context optionnel) — le numéro de ticket est recyclé par lieu, la résolution est scopée au lieu d'émission ;
accepter le format de ticket que vous exposez : brut (2) ou formaté (RA-2) ;
vérifier que la date de naissance correspond au patient du RDV — non concordant → 404 UNKNOWN_APPOINTMENT, jamais le RDV d'un autre patient ;
réponse 200 : même forme que by-code (patient + appointment + otherAppointments).

Requête et réponse

bash

curl -sS -X POST "$BASE/appointments/by-ticket" "${AUTH[@]}" \
  -H "Content-Type: application/json" \
  -d '{ "ticketNumber": "RA-2", "birthDate": "1980-05-12", "officePlaceVisibleId": "loc-42" }'

200

{
  "patient": { "id": "pat-77", "firstName": "Marie", "lastName": "Durand", "birthDate": "1980-05-12" },
  "appointment": { "id": "apt-1001", "examLabel": "IRM lombaire", "status": "checkedIn", "ticketNumberFormatted": "RA-2" },
  "otherAppointments": []
}

Points d'attention

La date de naissance est une garde d'accès, pas un critère de recherche : un ticket valide avec une mauvaise naissance doit répondre 404 — sans indiquer si c'est le ticket ou la naissance qui est en cause (pas d'énumération possible).

Ce que le serveur ApiBorne fait de votre réponse

L'app Pass tourne dans le navigateur du patient et ne vous appelle jamais en direct : c'est le serveur ApiBorne qui relaie, en portant la clé de marque. Deux protections sont posées de son côté, à connaître pour dimensionner la vôtre :

Projection stricte vers le navigateur. De l'objet patient que vous renvoyez, seuls id, firstName et lastName atteignent le téléphone du patient. birthDate, socialSecurityId, email, mobilePhone, phone, address et vendorData s'arrêtent au serveur ApiBorne. Vous pouvez donc garder la même réponse que by-code sans exposer davantage.
Limitation de débit sur la vérification de naissance. Le serveur ApiBorne refuse (429) au-delà de 5 essais par 15 minutes pour un même couple ticket + lieu, et de 60 essais par minute par adresse IP, sans jamais atteindre votre route. Les échecs répétés sont journalisés chez ApiBorne. Vous n'avez pas de verrou à implémenter pour ce parcours ; votre 404 indifférencié reste la règle.

Ces limites ne concernent que les appels issus du Pass. La borne, elle, n'utilise pas cette route : elle identifie par carte Vitale, QR ou saisie via identify et by-code.

Implémentation de référence

src/app/api/apiborneIntegrationService/v1/appointments/by-ticket/route.ts → — la démo résout le ticket sur les RDV du jour du lieu, formats brut et formaté acceptés.