Faire une demande d'accès Wi-Fi

  • Transversal
  • Services
  • 1 route
Comment transmettre une demande d'accès Wi-Fi depuis le formulaire dédié ?

Ce scénario documente l'envoi des informations collectées dans un formulaire d'accès Wi-Fi via POST/v1/wifi_access_request. Il correspond à un parcours de demande de service dans lequel un canal recueille la demande puis la transmet à Club Med pour traitement.

La réponse documentée confirme actuellement si la demande est autorisée grâce au champ is_allowed. Le schéma exact du body n'est pas vérifiable avec la source disponible ; l'intégration doit donc s'aligner sur le contrat backend réellement utilisé par le formulaire Wi-Fi.

Vue d'ensemble

Utilisez ce scénario pour documenter la soumission d'une demande d'accès Wi-Fi collectée depuis un formulaire dédié. La route joue le rôle de point de transmission du parcours et expose une réponse de confirmation simple.

Prérequis

  • Un x-api-key valide
  • Un payload aligné avec le contrat du formulaire d'accès Wi-Fi
  • Un product_id dans le payload, car l'exemple de validation documenté l'indique comme requis

Résultat attendu

L'application peut transmettre la demande d'accès Wi-Fi et déterminer si elle est acceptée pour traitement grâce au champ is_allowed retourné en cas de succès.

Notes de périmètre

  • Ce parcours documente volontairement uniquement le point de soumission, car aucune route complémentaire dédiée à l'accès Wi-Fi n'est vérifiable dans la source disponible.
  • Le schéma détaillé du body et les règles de traitement aval ne sont pas vérifiables avec la source disponible.
1

Transmettre la demande d'accès Wi-Fi

Obligatoire

Objectif

Utiliser POST/v1/wifi_access_request pour transmettre les informations saisies dans le formulaire d'accès Wi-Fi. Cette route constitue le point de soumission du parcours et retourne si la demande est autorisée.

Paramètres

  • Header requis : x-api-key
  • Body de requête : le schéma exact n'est pas vérifiable avec la source disponible
  • Indice de validation connu : l'exemple documenté en 400 montre que product_id est requis dans le payload

Exemple de requête

# Le schéma JSON exact n'est pas vérifiable avec la source disponible.
curl -X POST \
  "https://api.clubmed.com/v1/wifi_access_request" \
  -H "x-api-key: YOUR_API_KEY" \
  --data-binary '<payload du formulaire Wi-Fi>'

Points clés de la réponse

{
  "is_allowed": true
}
  • is_allowed indique si la demande d'accès Wi-Fi transmise est acceptée par l'API
  • Une réponse 200 OK confirme que les données du formulaire ont été transmises dans un format accepté par l'endpoint

Erreurs et warnings

WARNING

Le schéma exact du payload n'est pas visible dans la source disponible. Il faut confirmer le contrat backend réellement utilisé par le formulaire Wi-Fi avant l'implémentation.

  • 400 bad_request ou validation_error signale un payload invalide ou incomplet
  • L'exemple de validation documenté mentionne explicitement FIELD_REQUIRED sur product_id
  • Seules les réponses 200 et 400 sont vérifiables dans la source disponible
POST/v1/wifi_access_request
Voir plus