Check-list de conformité

• Base path exact /api/apiborneIntegrationService/v1/, JSON camelCase, dates ISO 8601.
• Les 2 headers d'auth validés sur toutes les routes (401 typés, device d'abord).
• context.config honoré ; aucun appel sortant vers le serveur ApiBorne pendant un parcours.
• Propriétés inconnues de context.config.* ignorées silencieusement.
• Erreurs au format { "error": { code, message, details } } avec les statuts du contrat.
• Identifiants opaques stables pendant tout un parcours ; un appointment.id ne doit jamais valoir littéralement by-code (collision de route).
• identify : tous critères combinés, NIR prioritaire, patients: [] si rien.
• by-ticket : 404 UNKNOWN_APPOINTMENT indifférencié (ticket inconnu ou naissance non concordante) ; la limitation de débit du parcours Pass est assurée par le serveur ApiBorne, pas par vous.
• Identifiants de RDV non énumérables (pas de séquence) : l'app Pass recharge un RDV par GET /appointments/{id} sans date de naissance.
• Upload : ≥ 10 Mo acceptés, réponse en moins de 60 s, 413 typé au-delà de votre limite.
• Check-in idempotent (rejeu après timeout → même ticket).
• notification-readiness répond toujours (au pire { "ready": true }).
• deferExternalNotification honoré (arrivée enregistrée, notification reportée, awaitingExternalNotification: true) — ou ignoré, jamais rejeté.
• PUT status accepte closed ; un système à un seul état final le mappe sur closed et traite done comme intermédiaire.
• downloadAppointmentDocument : pages en base64 sans préfixe data:, ou 404 UNKNOWN_DOCUMENT systématique si vous ne servez pas les contenus.
• Les extensions passent par vendorData — la spec de référence n'est jamais modifiée.

Comment dérouler ces tests (curl en local, ngrok, sonde config-check, banc de test des endpoints de l'admin avec vos propres entrées) : voir le guide Tester votre implémentation.

• identify sans headers → 401 avec un corps normalisé.
• identify avec un NIR contenant des espaces → le patient est trouvé.
• by-code avec un code inconnu → 404 UNKNOWN_APPOINTMENT.
• check-in avec un proposedTicket → la réponse reprend ce ticket.
• Le même check-in rejoué → 200 avec le même ticket (pas de doublon).
• check-in d'un RDV terminé/annulé → 409 ALREADY_CHECKED_IN.
• Upload au-delà de votre limite → 413 UPLOAD_TOO_LARGE.
• PUT status en arrière (inCare → checkedIn) → 200 sans effet.
• staff/sign-in avec de mauvais identifiants → 401 INVALID_CREDENTIALS.
• PUT status closed puis done → 200 sans effet (progression avant uniquement).
• notify-external-system sur un RDV non accueilli → 409 ; rejoué sur un RDV déjà notifié → 200 sans renotifier.