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.
• 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 }).
• 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.