Tester votre implémentation

1. Auto-tests curl — pendant le développement, en local, sans rien configurer côté ApiBorne ;
2. Sonde config-check — automatique dès que votre serveur est déclaré dans l'admin ApiBorne : elle valide la forme de vos référentiels et déverrouille la configuration (l'indicateur bouclier, ex. 9/9) ;
3. Banc de test des endpoints — dans l'admin ApiBorne, page Test du contrat : vous choisissez une route, saisissez vos entrées (nom, date de naissance, id de RDV…) et obtenez un rapport détaillé de l'appel réel.

Votre serveur de développement tourne en local ? Voyez d'abord comment le brancher à ApiBorne avec ngrok.

Avant toute configuration ApiBorne, vérifiez chez vous les fondamentaux : enveloppes de réponse, auth, identification. La $AUTH_KEY est la clé que votre serveur attend (en dev, celle de votre seed de test — voir le guide Authentification).

# Variables : votre serveur local + les identifiants de test
BASE="http://localhost:3020/api/apiborneIntegrationService/v1"
AUTH=(-H "X-Kiosk-Auth-Key: $AUTH_KEY" -H "X-Kiosk-Device-Id: TEST-001" -H 'Content-Type: application/json')

# Un référentiel répond avec la bonne enveloppe ?
curl -sS "$BASE/config/office-places" -H "X-Kiosk-Auth-Key: $AUTH_KEY"
# → 200 { "officePlaces": [ { "id": "1", "name": "…" } ] }

# L'auth est bien validée ? (sans headers → 401 normalisé)
curl -sS -o /dev/null -w '%{http_code}\n' "$BASE/patients/identify" -X POST
# → 401

# L'identification trouve votre patient de test ?
curl -sS "$BASE/patients/identify" "${AUTH[@]}" -d '{
  "criteria": { "lastName": "DURAND", "firstName": "MARIE", "birthDate": "1980-05-12" }
}'

La check-list de conformité donne la liste complète des tests exécutables (idempotence du check-in, 413 sur upload, statuts en arrière…).

Le serveur ApiBorne (et la borne) doivent pouvoir joindre votre implémentation. En développement, votre serveur tourne sur votre poste — ngrok l'expose en HTTPS en une commande :

# 1. Votre implémentation tourne en local (ex. port 3020)
npm run dev

# 2. Exposez-la sur Internet avec ngrok
ngrok http 3020
# → Forwarding  https://a1b2c3.ngrok-free.app -> http://localhost:3020

# 3. Dans l'admin ApiBorne (page Intégration, onglet intégration libre) :
#    Base URL du contrat = https://a1b2c3.ngrok-free.app
#    → Appliquer, puis Activer

• l'URL ngrok change à chaque relance (offre gratuite) : re-renseignez la base contrat après chaque redémarrage, ou réservez un domaine fixe (offre payante) ;
• le tunnel transmet le header Host ngrok : si votre framework valide les hosts (Next.js, Django…), autorisez le domaine ngrok en dev ;
• la borne appelant depuis un navigateur, votre CORS doit accepter l'origine de la borne — le tunnel n'y change rien (voir Authentification).

Dès que votre intégration est déclarée (page Intégration de l'admin ApiBorne), le serveur ApiBorne sonde automatiquement l'endpoint contrat et les routes de configuration : l'indicateur bouclier de la barre supérieure affiche le score (ex. 9/9) et son popover détaille chaque vérification — compte KioskReactor, endpoint contrat, puis chaque référentiel (lieux, types d'examen, praticiens, salles, examens). Une croix rouge en face d'une route = elle ne répond pas ou pas avec la forme attendue ; tant que tout n'est pas vert, la configuration des bornes reste verrouillée. Relancer re-sonde immédiatement après une correction.

La page Test du contrat de l'admin ApiBorne (menu Configuration, intégrations libres uniquement) exécute un appel réel vers votre serveur — avec la clé, les chemins et le header office configurés — et rend un rapport complet :

• vos entrées : critères d'identification (nom, prénom, date de naissance, NIR), code de convocation, id de RDV, identifiants personnel… selon la route choisie ;
• la requête envoyée telle quelle (méthode, URL résolue, headers — clé masquée, corps) : ce que vous devez voir arriver dans vos logs ;
• le verdict : statut HTTP, durée, réponse brute, et des vérifications de conformité par route — enveloppe correcte, erreurs normalisées (404 UNKNOWN_APPOINTMENT, 401 INVALID_CREDENTIALS), requiredDocumentTypes en objets et pas en chaînes, ready booléen…

Les routes proposées sont les lectures du contrat (identify, by-code, by-id, documents, readiness, staff/sign-in) et les 6 routes de configuration. Testez avec de vraies données de votre base de test : un identify qui renvoie 0 patient est conforme, mais ne prouve pas grand-chose.

Le banc de test ne déclenche volontairement aucune écriture (check-in, PATCH patient, upload…) : elles modifient vos données. Pour les tester en conditions réelles, déroulez un parcours complet sur une borne en mode simulation (?simulate=true, sans matériel) pointée sur votre serveur : identification, correction de fiche, scan de documents, check-in — puis vérifiez le rejeu du check-in (même ticket) et l'idempotence avec les tests curl de la check-list.