Comparer et appliquer des contre-propositions
- Services
- 10 routes
Ce scénario explique comment Club Med expose des contre-propositions autour d'une demande de voyage. Le parcours couvre d'abord la suggestion de dates alternatives à partir des critères de recherche, puis l'exploration d'alternatives sur une proposition déjà créée, comme le package, le tarif, le transport ou l'hébergement.
L'objectif est d'aider un intégrateur à construire un écran de comparaison fiable : partir d'une proposition de référence, lire son état courant, la rafraîchir si nécessaire, puis présenter uniquement les variantes réellement applicables.
Vue d'ensemble
La notion de contre-proposition ne correspond pas à une seule route. Elle s'appuie sur plusieurs ressources qui interviennent à différents moments du tunnel de réservation :
- avant la sélection finale, avec
POST/v0/proposals/date_suggestionpour proposer d'autres dates ; - après la création d'une proposition, avec des routes dédiées aux alternatives de package, de tarif, de transport ou de confort d'hébergement.
Prérequis
- Disposer d'une
x-api-keyvalide. - Fournir un
accept-languagesur les routes qui l'exigent. - Avoir les critères de réservation permettant de créer une proposition de référence.
- Disposer d'un
proposal_idvalide pour les étapes de lecture, rafraîchissement et arbitrage des alternatives. - Prévoir un bearer token lorsque votre contexte d'intégration le requiert.
Résultat attendu
À la fin du parcours, l'application peut :
- générer une proposition de référence ;
- lister des contre-propositions par date ;
- relire puis rafraîchir la proposition retenue ;
- afficher les alternatives applicables sur le package, le tarif, le transport et l'hébergement ;
- appliquer une alternative de package ou de tarif lorsque la route correspondante est utilisée.