595 solutions pour construire votre écosystème B2B tourisme.
Distribution, hôtellerie, restauration, activités, mobilité, paiement, data, logiciels, voyages d’affaires et création web : filtrez selon votre besoin et votre métier. Chaque fiche résume l’usage principal de la solution, les profils auxquels elle peut convenir et les points à examiner avant d’aller plus loin.
Répertoire opérationnel
Trouver le bon partenaire selon le produit, le profil et le niveau d’intégration.
Commencez par un seul besoin prioritaire, puis affinez avec votre profil et le mode d’accès souhaité. Une liste courte de trois à cinq acteurs est généralement plus utile qu’une longue sélection impossible à comparer sérieusement.
284solutions correspondantes
eSIM / partenairesaffiliation
Ubigi
Ubigi présente pour le tourisme un programme Wholesale associant intégration API et plateforme de gestion eSIM. La page distingue le catalogue de plans et leur distribution dans l’expérience du partenaire.
Pour quel besoin ? Agence, média ou distributeur qui veut choisir entre orientation et revente d’un plan de données.
Test conseillé : Vérifier programme, terminal compatible, validité du plan, livraison et assistance sur une activation impossible.
En savoir plus
Faits, limites et références (1)
Limite : Programme présenté ; couverture, compatibilité du terminal et démarrage de validité sont à vérifier plan par plan.
À demander : Quel événement démarre la validité du plan distribué et qui prend en charge l’assistance ?
Le parcours Reseller présente un contrat, une documentation technique sur demande et l’obtention d’une clé API. La page mentionne une connexion à Stripe ou un dépôt remboursable pour activer la revente, distincte de l’affiliation ou de la vente en gros.
Pour quel besoin ? Distributeur qui veut proposer des plans adaptés aux étapes d’un voyage et au modèle commercial choisi.
Test conseillé : Comparer un plan terrestre et une offre en mer ou en vol sans extrapoler leur couverture ; rejouer commande et support.
En savoir plus
Faits, limites et références (1)
Limite : Conditions de programme décrites ; l’activation et les modalités financières applicables au partenaire restent à confirmer.
À demander : Quelles étapes séparent votre accord de partenariat d’une revente effectivement active ?
Nomad distingue sur sa page partenaire un programme d’affiliation, une collaboration avec les créateurs et d’autres partenariats de marque. Le suivi des conversions est présenté dans le programme affilié.
Pour quel besoin ? Média, guide ou agence qui souhaite recommander une connectivité avec redirection vers le vendeur.
Test conseillé : Vérifier liens, attribution, compatibilité du plan choisi et circuit d’aide après redirection.
En savoir plus
Faits, limites et références (1)
Limite : Page de partenariat ; conditions d’attribution, validation, rémunération et possibilités de commande doivent être confirmées pour le programme accepté.
À demander : Comment séparer clic suivi, achat attribué, conversion validée et service réellement utilisable ?
À réunir : Cas fictif : média M3 admis à un programme de contenu. Retrouver les droits obtenus ; ne pas transformer l’accord de contenu en capacité de vente par API.
Attribution
À réunir : Dix achats attribués, dont deux encore à valider dans le suivi fictif. Distinguer les huit validés des dix observés ; ne pas présenter toutes les attributions comme une rémunération acquise.
Produit
À réunir : Plan P3 acheté, installation observée mais connexion non vérifiée. Renvoyer vers le support et les conditions du plan ; l’achat ne prouve pas l’accès aux données.
Support
À réunir : Demande voyageur accompagnée d’une référence de plan autorisée. Identifier l’interlocuteur et les informations nécessaires sans recopier de code d’activation.
BNESIM distingue un programme affilié par lien, un distributeur fixant ses prix de revente, un partenaire API et une offre en marque blanche personnalisable. Le tableau de bord figure dans les modèles distributeur et API présentés.
Pour quel besoin ? Plateforme ou distributeur qui veut relier son parcours à des commandes de connectivité.
Test conseillé : Tester les états de commande, la livraison et une activation impossible, puis retrouver les responsabilités de support.
En savoir plus
Faits, limites et références (2)
Limite : Présentation de programmes ; commissions, fonctions, couverture et responsabilités dépendent du modèle et de l’accord retenus.
À demander : Quel modèle est prévu et qui contrôle prix, marque, livraison et service client ?
calendar_dates active ou retire un service pour une date ; ses exceptions modifient le calendrier régulier correspondant.
Pour quel besoin ? Préparer les accès aux destinations et lieux touristiques à partir d’une offre de transport identifiée ; il ne s’agit pas d’un vendeur de billets.
Test conseillé : Rapprocher un lieu, son arrêt et une course à la date réelle, y compris exception de calendrier, horaire tardif et absence de temps réel.
En savoir plus
Faits, limites et références (1)
Limite : Spécification de données planifiées ; un calendrier GTFS ne confirme ni circulation réelle, ni billet réservé, ni disponibilité d’un véhicule privé.
À demander : calendar_dates peut-il retirer un service ?
Lecture automatique refusée (HTTP 403) · contrôle du 05/11/2026 · Portée du contrôle
Air / standardNDC
IATA NDC
Standard de distribution basé sur les offres et commandes, utile pour accéder à du contenu aérien riche via compagnies, GDS ou agrégateurs.
Pour quel besoin ? Équipe de distribution qui doit comprendre le rôle du standard avant de comparer les accès offerts par une compagnie, un GDS ou un agrégateur.
Test conseillé : Demander au partenaire choisi de jouer recherche, offre, commande, modification et service sur une compagnie et une version de messages précis.
En savoir plus
Autres points à examiner
Point de départ pour comprendre NDC, Offer/Order et les exigences de distribution aérienne.
À combiner avec un agrégateur ou un GDS si l’équipe ne veut pas gérer chaque compagnie une par une.
Faits, limites et références (1)
Documenté : NDC définit un cadre d’échange fondé sur les offres et commandes, accessible aux acteurs de la distribution.
Limite : La spécification ne fournit ni inventaire ni autorisation d’émettre des billets.
À demander : Quelle version est déployée, avec quelles opérations et quels partenaires ?
Portail désormais consacré aux API Enterprise Amadeus. L’annonce officielle indique le retrait du portail Self-Service au 17 juillet 2026 ; les anciens tutoriels ne constituent plus une voie d’accès à cette offre.
Pour quel besoin ? Équipe qui doit examiner un accès Enterprise ou organiser la reprise d’une intégration historique, avec un contrat et un périmètre confirmés.
Test conseillé : Faire confirmer le produit et l’accès actuels, puis tester recherche, réservation, émission et service sur les opérations effectivement autorisées.
En savoir plus
Autres points à examiner
Identifier le produit, la documentation actuelle et le mode d’accès avant de prévoir un prototype.
Faire confirmer l’ouverture du compte, les opérations disponibles et le passage à la production.
Faits, limites et références (1)
Documenté : Le portail présente les API Enterprise, avec demande d’accès et sandbox Enterprise. L’accès aux anciens exemples Self-Service ne démontre pas l’ouverture d’un produit Enterprise à une nouvelle entreprise.
Limite : Portail de gamme et d’accès ; opérations, contenus, contrat et passage en production restent à confirmer pour l’entreprise.
À demander : Quelle preuve relie le prototype autorisé à notre futur parcours d’émission et d’après-vente ?
À réunir : Cas fictif : prototype hôtel H7, projet de vente aérienne A7. Identifier séparément les produits et accès nécessaires ; un essai hôtelier ne couvre pas le besoin aérien.
Environnement
À réunir : Compte, autorisation et documentation du produit retenu. Distinguer environnement de test, contenu de démonstration et service de production accepté.
Engagement
À réunir : Recherche, commande et document d’émission attendus pour A7. Demander une preuve à chaque étape ; un résultat de recherche ne constitue pas un billet.
Relais
À réunir : Dossier ouvert, référence et acteur chargé d’une modification. Vérifier qui reprend le suivi et avec quel accès avant de généraliser le prototype.
Écosystème Sabre pour agences connectées et partenaires développeurs, avec accès au portefeuille d’APIs et à des solutions tierces.
Pour quel besoin ? Éditeur ou agence qui veut relier un outil métier à des services Sabre et identifier les intégrateurs adaptés à son marché.
Test conseillé : Choisir une opération réelle, vérifier accès, documentation, limites et responsabilité du support avant de construire un parcours de réservation complet.
En savoir plus
Autres points à examiner
À regarder si l’agence travaille déjà dans l’environnement Sabre.
Le Partner Hub aide à trouver des partenaires technologiques compatibles.
Faits, limites et références (1)
Documenté : La collection NDC distingue recherche, tarification, création de commande et fulfillment. Elle décrit aussi des parcours d’après-vente, dont revalidation et annulation, selon l’état de la commande.
Limite : Collection NDC citée ; les droits du compte, compagnies et opérations réellement ouverts doivent être établis séparément.
À demander : Comment distinguer une commande créée d’un dossier effectivement émis sur notre compagnie cible ?
À réunir : Cas fictif : O71 créée, sans document d’émission retrouvé. Conserver cet état sans annoncer le billet comme disponible ; rechercher le résultat du fulfillment.
Offre
À réunir : Offre sélectionnée V1 puis tarif relu V2. Comparer prix, bagages et conditions avant l’engagement, même si le montant n’a pas changé.
Après-vente
À réunir : Annulation demandée avant émission, puis cas après émission. Demander le parcours autorisé dans chacun des deux états, avec la réponse et les références obtenues.
Reprise
À réunir : Réponse perdue après une action sur O71. Retrouver la commande et ses documents avant de répéter une opération ou de créer un autre dossier.
Le guide distingue le cache de recherche (12 minutes pour GDS, 34 pour NDC) et la session workbench (30 minutes, avec commit avant expiration). Dans le parcours standard de réservation retenue, commit et émission restent distincts ; les autres parcours ont leurs règles propres.
Pour quel besoin ? Équipe produit qui veut construire un parcours distribuant plusieurs types de contenu tout en gardant la maîtrise de l’interface.
Test conseillé : Sur une compagnie et un hébergement accessibles, rejouer recherche, prix, réservation, modification et annulation en conservant les références de chaque étape.
En savoir plus
Autres points à examiner
Convient aux agences et plateformes qui veulent un socle GDS/NDC structuré.
Les workflows de réservation imposent des délais et états de session à respecter.
Faits, limites et références (2)
Limite : Workflow Flights : ne pas généraliser une procédure d’émission à tous les contenus GDS et NDC.
À demander : Quelle preuve distingue la réservation retenue du titre utilisable ?
Après Search, la lecture autonome vise un seul produit par appel via productIDs. Pour une réservation existante, le guide exige un dossier créé par TripServices avec un tarif et un fare basis valides ; il exclut le split ticketing de ce parcours.
Portée : Périmètre TripServices Air v11 documenté par Travelport, consulté le 22 octobre 2026. Les limites décrites ne valent pas pour tous les produits Travelport ni pour toutes les opérations d’un transporteur. Une règle récupérée ne prouve pas l’exécution d’un échange ou d’un remboursement.
Contrôles proposés pour ce périmètre
Cache Search GDS
À réunir : Le guide publie une fenêtre de 12 minutes pour les requêtes de référence issues de la recherche GDS.. Noter l’heure de recherche ; ne pas utiliser la durée du workbench à la place.
Cache Search NDC
À réunir : La fenêtre publiée pour la recherche NDC est de 34 minutes.. Conserver le type de contenu avec la référence.
Session
À réunir : Identifiant et heure de création. Suivre l’expiration du workbench.
Commit
À réunir : Résultat et locator. Rechercher la réservation après une réponse perdue.
Émission
À réunir : Documents et échéance retournés. Vérifier le parcours applicable au contenu.
Reprise
À réunir : État courant du dossier. Éviter une nouvelle réservation sans rapprochement.
Les bagages inclus dans le billet et ceux achetés en supplément ne figurent pas au même endroit dans la commande. Chaque service est associé à des segment_ids et passenger_ids.
Pour quel besoin ? Plateforme qui souhaite intégrer une offre aérienne dans son propre parcours client.
Test conseillé : Créer une commande, ajouter un bagage puis simuler changement ou annulation en vérifiant les actions possibles selon le transporteur.
En savoir plus
Autres points à examiner
Intéressant pour startups, néobanques, conciergeries et OTAs qui veulent lancer vite.
Peut utiliser son accréditation et son autorité de billetterie selon le montage.
Faits, limites et références (12)
Limite : Disponibilité des bagages additionnels selon compagnie et offre. Le document EMD n’est pas garanti pour chaque réservation.
À demander : Vérifier les voyageurs et les vols couverts avant de présenter le supplément comme valable sur tout le voyage.
expires_at donne l’expiration de l’offre ; une nouvelle lecture ne garantit pas sa disponibilité à la réservation. total_amount inclut les taxes pour les voyageurs, mais exclut les services supplémentaires. Une ventilation tax_breakdown vide ou partielle ne permet pas de reconstituer le total.
Portée : Champs de l’offre et limites de la ventilation des taxes ; les règles de réservation, de services et d’après-vente doivent aussi être contrôlées pour le trajet retenu.
Les jetons de test et de production accèdent à des ressources séparées. Duffel Airways simule les parcours, avec des horaires et prix artificiels ; les sandboxes des compagnies externes ont leurs propres limites.
Portée : Un résultat en simulation ne démontre ni disponibilité commerciale ni couverture après-vente d’une compagnie réelle.
order.airline_initiated_change_detected signale un changement initié par la compagnie. Le contrôle emploie X-Duffel-Signature et un secret ; ce secret n’est montré qu’à la création du webhook. Duffel indique d’utiliser idempotency_key pour l’unicité des événements rejoués.
Portée : Comportement décrit par Duffel, à ne pas généraliser aux webhooks de tous les fournisseurs.
Un siège sans available_services, représenté par une liste vide, est indisponible dans ce parcours. Un même siège peut avoir un service et un prix différents selon le passenger_id. Dans services, chaque siège se transmet avec son id de service et quantity égal à 1. Le paiement inclut le prix de l’offre et des services choisis. La réponse de commande contient les sièges dans services et leur désignation dans seat pour le passager du segment.
Portée : Parcours Duffel documenté, sans extension à toutes les compagnies ni garantie de conservation du siège après changement de vol ou d’appareil.
booking_references contient la référence principale et les références supplémentaires des compagnies du dossier. Chaque entrée réunit booking_reference et carrier, la compagnie ayant émis cette référence. La référence propre au transporteur peut servir à l’enregistrement et au choix de siège auprès de celui-ci. Le champ historique booking_reference reste la référence principale.
Portée : Évolution annoncée le 7 août 2025, vérifiée le 22 octobre 2026. La liste de PNR ne constitue pas une carte d’embarquement.
requires_instant_payment: false indique qu’une offre peut être retenue sans paiement immédiat. price_guarantee_expires_at indique la fin de garantie du prix. Une valeur null signifie que le prix peut changer pendant la retenue. Sans paiement avant payment_required_by, la compagnie libère la place et awaiting_payment passe à false. Relire la commande donne le prix courant ; un montant devenu ancien peut produire l’erreur price_changed.
Portée : Exemple fictif : prix garanti jusqu’à 16 h et paiement exigé avant 18 h, dans le même fuseau. À 17 h, la place peut encore être retenue sans que le prix de 15 h soit garanti. Ces heures illustrent la distinction ; elles ne sont pas des délais Duffel.
Places distingue type: city et type: airport. airports est fourni pour une ville ; city décrit l’aire métropolitaine d’un aéroport lorsqu’IATA l’y rattache. Le schéma illustre iata_code par LHR (aéroport), iata_city_code par LON (ville), icao_code par EGLL et iata_country_code par GB. time_zone utilise un nom de la base tz ; latitude, longitude et time_zone peuvent être null. Le paramètre rad de /places/suggestions est exprimé en mètres.
Portée : Schéma Duffel consulté le 22 octobre 2026. Les exemples de code expliquent les champs ; l’aéroport effectivement réservé doit être retrouvé dans les segments du voyage.
ratelimit-limit donne le plafond de la période et ratelimit-remaining le nombre restant. Le code rate_limit_exceeded demande d’attendre le moment indiqué par ratelimit-reset, exprimé comme une date HTTP. Le tableau Duffel demande de ne pas réessayer les erreurs serveur 500 et 502 et de transmettre le request_id au support.
Portée : Comportement Duffel documenté. Aucune limite de compte ni autorisation de nouvelle réservation ne découle de cet exemple ; une écriture à résultat incertain doit être rapprochée séparément.
Contrôles proposés pour ce périmètre
Périmètre du supplément
À réunir : Chaque service est associé à des segment_ids et passenger_ids.. Vérifier les voyageurs et les vols couverts avant de présenter le supplément comme valable sur tout le voyage.
Après réservation
À réunir : Les bagages supplémentaires réservés figurent dans services, sans être ajoutés à slices[].segments[].passengers[].baggages[].. Réunir les deux informations pour établir la franchise totale du voyageur.
Quantité
À réunir : Le service disponible expose maximum_quantity ; le service réservé expose quantity.. Distinguer plafond proposé et quantité réellement achetée.
Document
À réunir : Certaines compagnies émettent un document EMD ; Duffel le décrit par electronic_miscellaneous_document_associated lorsqu’il est disponible.. Conserver aussi les documents de services, distincts du billet électronique.
La documentation distingue expiration de la garantie de prix, échéance de paiement et statut de paiement. Une commande non payée peut être libérée à son échéance.
Garantie de prix
Conserver price_guarantee_expires_at et le prix relu.
Échéance de paiement
Conserver payment_required_by avec son fuseau.
Preuve d’émission
Rapprocher documents et paiement ; awaiting_payment seul ne suffit pas.
Scénario proposé : Rejouer une commande dont la garantie de prix expire avant le délai de paiement ; comparer la nouvelle offre avant toute décision.
Portée : Fonction de mise en attente variable selon la compagnie ; ce contrôle documentaire n’émet aucun billet.
Contrôles éditoriaux proposés, à rejouer sur votre périmètre ; aucun appel à une API fournisseur ni test de réservation effectué.
AirGateway distingue un sandbox relié aux environnements de test des fournisseurs et une plateforme LIVE accessible après certification.
Pour quel besoin ? OTA, outil de réservation d’entreprise ou consolideur qui souhaite ajouter du contenu aérien direct sans maintenir autant de connexions propres.
Test conseillé : Comparer la même offre via le canal existant et l’API, puis vérifier émission, changement, remboursement et reprise du dossier dans le poste agent.
En savoir plus
Autres points à examiner
Approche utile pour agences IATA, TMC, OBT et consolidateurs.
Passage sandbox puis certification avant production.
Faits, limites et références (1)
Limite : Présentation de l’API ; compagnie, marché, opération et moyen de paiement ouverts en production dépendent du partenariat confirmé.
À demander : La certification confirme-t-elle toutes les compagnies ?
La fonction Reprice de BookingPad compare les données actualisées de la commande avant émission. Le besoin de revalidation manuelle dépend du fournisseur.
Ancienne offre
Archiver prix, tarif et bagages présentés.
Offre réévaluée
Comparer les conditions modifiées, pas seulement le total.
Décision du conseiller
Dater l’acceptation ou le refus du changement.
Scénario proposé : Faire examiner une offre dont les bagages changent lors de la revalidation, même si le prix reste identique.
Portée : Présentation de BookingPad ; ne prouve pas un comportement identique de tous les transporteurs ou de tous les endpoints.
Contrôles éditoriaux proposés, à rejouer sur votre périmètre ; aucun appel à une API fournisseur ni test de réservation effectué.
Travelfusion présente tfFlight API pour recherche, choix, réservation, services complémentaires, paiement et traitement des dossiers aériens dans une plateforme de distribution.
Pour quel besoin ? Distributeur ayant besoin de comparer plusieurs sources aériennes et de garder un traitement cohérent après la vente.
Test conseillé : Tester un tarif avec bagage, un changement puis une annulation sur deux compagnies de modèles différents ; relever réponses, coûts et étapes qui exigent une intervention.
En savoir plus
Autres points à examiner
À regarder pour accès large aux low-cost et compagnies connectées en direct.
Bon candidat pour comparateurs, OTAs et corporate travel.
Faits, limites et références (1)
Limite : La présence d’une opération dans la présentation ne garantit pas sa disponibilité pour chaque compagnie, contenu ou compte. Le périmètre de servicing doit être testé avec les accès réellement accordés.
À demander : Quelles opérations de modification, annulation et remboursement sont disponibles pour chaque contenu retenu, avec quelles références et limites ?
La Smart Selling Platform présente une API normalisant NDC, LCC, GDS et marketplace de consolidateurs, avec gestion des offres et commandes et automatisation après réservation.
Pour quel besoin ? Vendeur de vols qui veut rapprocher des offres issues de circuits de distribution différents dans un même processus.
Test conseillé : Comparer prix final et bagages sur un trajet, puis suivre émission, échange et remboursement avec les mêmes identifiants de dossier.
En savoir plus
Autres points à examiner
Utile si la priorité est la normalisation d’un contenu aérien fragmenté.
Inclut portail agent, API, règles de sourcing et opérations post-booking.
Faits, limites et références (1)
Limite : La normalisation ne prouve pas une égalité de capacités entre sources ; l’après-vente doit être contrôlé par contenu.
À demander : Quelles opérations de modification, séparation de dossier et remboursement sont disponibles pour chaque source retenue ?
Kyte décrit une API de distribution réunissant accès à des contenus LCC et NDC, services complémentaires et opérations de suivi pour vendeurs de voyages et compagnies.
Pour quel besoin ? Plateforme de voyage qui veut ajouter du contenu aérien tout en conservant la maîtrise de son expérience de vente.
Test conseillé : Vérifier un trajet aller-retour avec options, prix total, création du dossier et assistance disponible après la vente.
En savoir plus
Autres points à examiner
Approche pensée pour les vendeurs qui ne veulent pas reconstruire une connexion par compagnie.
À évaluer pour une stack aérienne légère et centrée API.
Faits, limites et références (1)
Limite : Un accès unifié ne rend pas identiques les règles des compagnies. Les opérations possibles et les contenus autorisés doivent être vérifiés par marché et par fournisseur.
À demander : Quel cas montre recherche, ajout d’un service et modification du dossier pour chaque compagnie, avec ses identifiants et responsabilités ?
API pour distribuer des contenus interline, alternatifs et intermodaux, avec protection de correspondance et gestion des commandes.
Pour quel besoin ? Compagnie ou vendeur qui souhaite proposer un trajet combiné et doit comprendre la protection offerte au voyageur lors d’une correspondance manquée.
Test conseillé : Construire un itinéraire à deux opérateurs, simuler un retard du premier segment et documenter assistance, nouvelle réservation, paiement et information client.
En savoir plus
Autres points à examiner
À considérer pour construire des trajets multi-segments au-delà du simple vol point à point.
Adapté aux compagnies, OTAs et vendeurs travel avec ambition réseau.
Faits, limites et références (1)
Documenté : Retail Connect présente des connexions de vols et services distribuées par microsite ou API, ainsi qu’une protection des correspondances.
Limite : Un parcours assemblé et une protection additionnelle doivent être distingués d’un billet interligne unique.
À demander : Qui traite chaque segment, la correspondance manquée et la demande d’assistance ?
minimum_guest_age fixe l’âge minimum des personnes autorisées à séjourner ; minimum_checkin_age concerne la personne qui effectue l’enregistrement. Dans maximum_occupancy d’un produit disponible, une valeur children: null signifie qu’aucune information de tarif enfant applicable n’est renvoyée. free_stay décrit le prix ; un enfant gratuit peut toujours compter dans l’occupation de la chambre.
Pour quel besoin ? Média ou distributeur qui doit choisir entre contenu, recherche avec redirection et réservation sur son site.
Test conseillé : Vérifier l’éligibilité du niveau souhaité, puis comparer prix affiché, disponibilité, confirmation et données de rapprochement.
En savoir plus
Autres points à examiner
Couvre l’hébergement, et des briques autour voitures, attractions, commandes et messages selon documentation.
Pré-requis : compte Managed Affiliate Partner, token API et identifiant affilié.
Faits, limites et références (8)
Limite : Règles de lecture Demand API ; la composition autorisée dépend de la chambre, de la version appelée et du produit effectivement disponible.
À demander : Ne pas remplacer une restriction d’accueil par une règle de remise des clés.
La sandbox distingue les flux et services disponibles en test ; la collection de location de voitures n’y est pas disponible au moment de la consultation.
Portée : Périmètre documentaire de la sandbox. La collection location de voiture n’y est pas disponible selon cette page ; aucun essai en production proposé sans autorisation.
Dans le parcours Search, look and book, orders/preview fournit le prix et les conditions actuels ainsi qu’un order_token. Cette étape ne crée ni ne confirme la commande. Les avertissements et l’allocation des voyageurs doivent être traités avant orders/create ; une sélection modifiée exige une nouvelle preview.
Portée : Documentation de prévisualisation et création ; droits du compte et produits concernés à confirmer. La preview ne constitue pas une réservation.
included et excluded décrivent la position des frais par rapport au prix book ; ils ne désignent pas directement le bénéficiaire du paiement. Dans /orders/preview et /orders/create, les frais obligatoires calculables sont regroupés dans non_conditional et inclus dans total. Avec le mode incalculable, total_amount vaut null et le frais n’entre pas dans total. Le champ chargeable_online précise si la ligne peut être payée en ligne ; les frais conditionnels restent distincts. Les frais s’appliquent si le voyageur ne nettoie pas avant le départ. La condition concerne des frais de ménage par animal lorsque le voyageur vient avec un animal. La condition concerne le fait de fumer dans l’hébergement. Les frais conditionnels sont exclus de base, book et total. per_stay porte sur le séjour ; per_night multiplie par les nuits.
Portée : Modèle Demand API consulté le 22 octobre 2026. Les montants et conditions restent ceux du produit réservé ; cette lecture ne fixe aucun barème fiscal local. Référence Demand API consultée le 22 octobre 2026. Les montants de l’exemple sont fictifs. Une condition explique le modèle de la ligne ; elle ne prouve pas qu’un événement s’est produit dans un séjour réel.
Dans le preview d’hébergement, method_required indique si un moyen de paiement doit être fourni pour l’option choisie. Les cartes disponibles figurent dans general_policies.payment.<timing>.methods.cards du preview. Avec l’extra payment, /accommodations/details expose payment.methods.cards, virtual_cards et éventuellement cash. Dans le modèle de paiement sur place géré par Booking.com, l’établissement ne reçoit pas la carte du voyageur via Demand.
Portée : Périmètre hébergement Demand 3.2 et 3.3, consulté le 22 octobre 2026. method_required n’est pas renvoyé dans les previews de location de voiture.
Par défaut, accommodations/search renvoie le produit disponible le moins cher pour chaque hébergement répondant aux critères. La direction de tri par défaut est descending ; le guide demande ascending pour faire remonter les prix les plus bas. Le guide demande latitude, longitude et rayon dans coordinates pour utiliser distance. Un filtre sur le prix nécessite le paramètre currency.
Portée : Périmètre : hébergements dans Booking.com Demand API, selon la version et le contrat applicables. Ces règles ne décrivent pas le classement de tous les moteurs ni un temps de trajet.
Contrôles proposés pour ce périmètre
Âge du séjour
À réunir : minimum_guest_age fixe l’âge minimum des personnes autorisées à séjourner ; minimum_checkin_age concerne la personne qui effectue l’enregistrement.. Ne pas remplacer une restriction d’accueil par une règle de remise des clés.
Valeur children: null
À réunir : Dans maximum_occupancy d’un produit disponible, elle signifie qu’aucune information de tarif enfant applicable n’est renvoyée.. Elle ne démontre ni une interdiction des enfants ni la capacité de les accueillir.
Gratuité
À réunir : free_stay décrit le prix ; un enfant gratuit peut toujours compter dans l’occupation de la chambre.. Conserver son âge réel et vérifier la capacité dans accommodations/details.
Prix retourné
À réunir : Le prix du produit tient déjà compte de la tarification enfant applicable.. Ne pas déduire une seconde fois une remise ou convertir l’enfant en adulte dans la suite du parcours.
current_refundability distingue refundable, non_refundable et partially_refundable ; refundable=false ne décrit pas seul une perte totale. Les montants de l’objet stay ne sont remboursables que si le séjour entier l’est.
Pour quel besoin ? Distributeur qui intègre de l’hébergement dans un parcours de réservation maîtrisé.
Test conseillé : Comparer contenu de chambre, taxes, conditions, prix revalidé, réservation et annulation sur plusieurs pays.
En savoir plus
Autres points à examiner
Idéal pour une OTA, une app ou un acteur fidélité qui veut un grand inventaire lodging.
Candidature et revue commerciale au cas par cas.
Faits, limites et références (8)
Limite : Règles du modèle Rapid consulté ; le montant applicable dépend du tarif réservé et de ses fenêtres de pénalité.
À demander : Lire le détail avant d’annoncer « aucun remboursement ».
Le lien de réservation provient de Price Check. La documentation Booking décrit la création du dossier et la récupération de l’itinéraire ; il faut contrôler le résultat plutôt que déduire une réservation d’un prix affiché.
Portée : Parcours de réservation Rapid documenté, sans validation d’un compte, d’un tarif ou d’une disponibilité en production.
Rapid documente un parcours distinct de réservation en attente puis de reprise, avec des liens et états propres à ce flux.
Portée : Fonction du parcours Rapid documenté ; son activation, sa fenêtre et ses produits doivent être confirmés pour le compte. Une attente ne vaut pas séjour confirmé.
Price Check vérifie un tarif sélectionné. Si le prix change, la réponse fournit de nouveaux détails et un lien de réservation pour ce prix ; si le tarif n’est plus disponible, elle permet de relancer une recherche.
Portée : Parcours Lodging décrit par Expedia ; un tarif relu ne prouve pas encore une réservation créée.
affiliate_reference_id doit être unique par réservation et conservé lors d’une reprise de la même demande. Retrieve peut employer la référence revendeur et l’email initiaux, ou itinerary_id et le lien de relecture retourné. Le guide recommande une relecture après 90 secondes sans réponse et un suivi des relectures pendant 30 minutes avant escalade au support.
Portée : Procédure propre à Rapid Lodging. Une réponse de relecture temporairement absente peut encore correspondre à une création en cours.
amenities peut être fourni au niveau property, room ou rate plan. L’objet contient id, un name localisé et, le cas échéant, value. Les listes de référence indiquent has_value. categories classe notamment accessibility, accessible_parking et accessible_wheelchair. attributes comporte notamment general et pets ; les exemples officiels distinguent « animaux acceptés » et « chiens seulement ».
Portée : Référence du modèle Rapid, sans garantie de disponibilité d’une chambre ni d’adéquation à un besoin d’accessibilité. Confirmer les caractéristiques décisives auprès de l’établissement.
AP3 demande d’afficher instructions et special_instructions dans le même espace. special_instructions peut demander de prévenir l’établissement de l’heure d’arrivée ou d’attendre des consignes envoyées par courriel. Le même champ peut signaler un accueil situé ailleurs que dans le bâtiment du séjour. La référence AP3 vise les objets checkin, checkout, fees et policies du contenu de l’établissement, présentés pour les chambres proposées.
Portée : Exigences du parcours Rapid Lodging consultées le 22 octobre 2026. Une instruction générale ne confirme pas l’acceptation d’une arrivée particulière ; les codes individuels restent dans le canal client approprié.
Expedia recommande les inclusions de la réponse Shop pour l’information tarifaire la plus récente, plutôt que la seule réponse Content. Les repas couvrent les clients de la réservation sauf instruction contraire, qui peut notamment apparaître dans le libellé « Breakfast for 2 ». Une inclusion peut figurer dans promotions.value_adds, avec frequency et person_count. all_rate_plans: true couvre tous les tarifs ; avec some_rate_plans: true, les tarifs concernés portent l’équipement 2111. Les restrictions figurent dans details. Des précisions peuvent figurer dans rates.special_offer_description, checkin.special_instructions ou policies.know_before_you_go.
Portée : Modèle Rapid consulté le 22 octobre 2026. Une inclusion ne décrit pas à elle seule les horaires, le lieu de service ou toutes les boissons.
Contrôles proposés pour ce périmètre
Remboursement partiel
À réunir : current_refundability distingue refundable, non_refundable et partially_refundable ; refundable=false ne décrit pas seul une perte totale.. Lire le détail avant d’annoncer « aucun remboursement ».
Nuitées exclues
À réunir : nonrefundable_date_ranges comprend les dates de début et de fin, avec taxes et frais des nuitées concernées.. Repérer les nuits touchées et les pénalités supplémentaires applicables.
Heure limite
À réunir : Le décalage ISO 8601 fourni dans cancel_penalties.start et end fait autorité pour le calcul et l’affichage.. Ne pas le reconstruire uniquement à partir de la localisation de l’hôtel.
Montants par séjour
À réunir : Les montants de l’objet stay ne sont remboursables que si le séjour entier l’est. Dès qu’une journée est non remboursable, ces montants par séjour le sont aussi.. Ne pas répartir automatiquement un montant par séjour au prorata des seules nuits remboursables.
Combinaison des pénalités
À réunir : Une même fenêtre peut combiner un montant fixe avec un nombre de nuits, ou avec un pourcentage ; nuits et pourcentage ne se combinent pas ensemble dans un même palier.. Conserver le type et la base de chaque composante au lieu d’imposer une formule unique.
rateKey doit être recopié entre opérations, sans interprétation de sa structure interne.
Pour quel besoin ? Distributeur qui souhaite intégrer plusieurs familles de prestations dans son propre parcours de réservation.
Test conseillé : Vérifier pour chaque API contenu, disponibilité, confirmation, modification et service, puis distinguer environnement d’essai et contrat commercial.
En savoir plus
Autres points à examiner
Socle classique pour agences, TO, DMC et OTAs qui veulent acheter du stock B2B.
Prévoir certification, gestion des quotas et conditions commerciales par marché.
Faits, limites et références (3)
Limite : Bonnes pratiques Hotel Booking API. Un recontrôle terminé ne constitue pas encore une confirmation de réservation.
À demander : Ne pas extraire dates ou occupation en découpant cette chaîne.
Hotel Booking API distingue Hotels, CheckRates et Bookings et s’appuie sur Hotel Content API pour les contenus. Un tarif rateType RECHECK demande une actualisation du prix et de la disponibilité via CheckRates.
Portée : La reconfirmation tarifaire reste distincte du résultat de réservation et des conditions effectivement acceptées.
Le workflow distingue rateType RECHECK, qui nécessite CheckRate pour actualiser prix et disponibilité avant réservation, et BOOKABLE, pour lequel cette étape intermédiaire n’est pas nécessaire.
Portée : Workflow de la Booking API hôtels ; cette règle ne décrit pas les autres produits Hotelbeds.
Contrôles proposés pour ce périmètre
Référence opaque
À réunir : rateKey doit être recopié entre opérations, sans interprétation de sa structure interne.. Ne pas extraire dates ou occupation en découpant cette chaîne.
Recontrôle ciblé
À réunir : CheckRates est requis pour RECHECK ; pour BOOKABLE, il peut être utilisé pour une information complémentaire telle que RateComments.. Ne pas recontrôler systématiquement chaque résultat de recherche.
Séquence
À réunir : Le guide recommande un seul rateKey par CheckRates et interdit de lancer CheckRates en même temps que la réservation.. Analyser la réponse du recontrôle avant la demande de confirmation.
Attente de réponse
À réunir : Le délai d’attente de confirmation doit être réglé à au moins 60 secondes.. Prévoir cette attente dans le parcours et distinguer délai dépassé et réservation refusée.
Recontrôle de plusieurs tarifs
À réunir : Les bonnes pratiques demandent de ne pas mélanger des rateKeys RECHECK et BOOKABLE dans une même opération CheckRates ; un seul rateKey par recontrôle est recommandé.. Conserver une réponse identifiable par tarif, sans transformer un échec de lot en refus de toutes les offres du séjour.
Origine du mapping hôtelier
À réunir : Hotelbeds demande de ne pas constituer le mapping hôtelier depuis l’environnement d’évaluation ou de préproduction.. Identifier l’environnement et la source du référentiel avant d’utiliser les correspondances dans un projet réel.
ETG décrit Prebook pour actualiser la disponibilité et rechercher un tarif comparable ; le prix changé doit être porté à la connaissance du client.
Pour quel besoin ? Agence ou plateforme qui veut afficher et réserver des hébergements dans son parcours plutôt que renvoyer vers un portail externe.
Test conseillé : Comparer pour un hôtel donné contenu, type de chambre, devise, prix total et conditions entre recherche et réservation, puis vérifier annulation et support.
En savoir plus
Autres points à examiner
À comparer avec Hotelbeds, Stuba, WebBeds et autres bedbanks selon destinations et marges.
Peut aussi passer par partenaires technologiques déjà connectés.
Faits, limites et références (1)
Limite : Flux et recommandations du guide ETG ; aucun tarif, accès partenaire ou engagement de réservation garanti pour votre compte.
Priceline décrit publiquement Partner Solutions comme une plateforme API de partenariats, avec accompagnement technique de l’intégration et de son exploitation.
Pour quel besoin ? Distributeur qui recherche une offre de voyage intégrée à son propre site ou service de fidélité.
Test conseillé : Demander le périmètre exact du contrat, puis comparer recherche, paiement, confirmation et assistance sur un dossier représentatif.
En savoir plus
Autres points à examiner
Adapté aux programmes de fidélité, agences, clubs, fintechs et plateformes e-commerce.
Permet une approche API ou modèle private label plus rapide.
Faits, limites et références (1)
Limite : La description officielle du rôle technique et le portail public ne donnent pas un accès ouvert à toute documentation. Catalogue, modèle de distribution et droits doivent être confirmés dans la proposition partenaire.
À demander : Quels produits et opérations sont autorisés pour notre canal, avec quelle documentation accessible et quel responsable de l’après-vente ?
Le portail distingue Content API et réservation HAPI : recherche, Booking Prepare, Booking Confirm, requête HCN, consultation et annulation. L’accès suit inscription, approbation et certification.
Pour quel besoin ? Agence ou plateforme disposant de développeurs et souhaitant afficher une offre hôtelière dans son parcours de vente.
Test conseillé : Comparer disponibilité et conditions sur deux chambres, réserver en environnement prévu à cet effet et rapprocher confirmation et annulation.
En savoir plus
Autres points à examiner
Intéressant pour agences et TO recherchant un fournisseur hôtel B2B curé.
Prévoir échanges avec l’équipe technique pour version, endpoint live et performance.
Faits, limites et références (1)
Limite : La préparation n’est pas la confirmation ; une référence hôtel HCN et un identifiant de réservation doivent être distingués.
À demander : Comment retrouver une confirmation après une réponse tardive et suivre l’obtention du HCN jusqu’au dossier client ?
Le parcours Hotel-X transmet l’identifiant d’option entre recherche, devis et réservation. Les accès et contextes déterminent le périmètre des données fournisseur.
Accès et contexte
Documenter access et la correspondance des codes.
Option du devis
Transmettre optionRefId issu de Quote sans l’interpréter.
Confirmation
Rapprocher référence locale et résultat de Book.
Scénario proposé : Comparer un devis revalidé avec la sélection initiale, puis vérifier la référence effectivement utilisée pour confirmer.
Portée : Un exemple de documentation ne donne ni accès commercial ni disponibilité d’un établissement.
Contrôles éditoriaux proposés, à rejouer sur votre périmètre ; aucun appel à une API fournisseur ni test de réservation effectué.
confirmationType distingue INSTANT, MANUAL et INSTANT_THEN_MANUAL.
Pour quel besoin ? Média ou marchand qui veut intégrer des expériences à une recherche de destination.
Test conseillé : Identifier Basic, Full, Full + Booking Affiliate ou Merchant ; vérifier séparément transaction, paiement, billet, annulation et responsable du service.
En savoir plus
Autres points à examiner
Grand classique pour tours, activités et expériences dans un guide ou une OTA.
Tester en sandbox, puis passer production uniquement pour transactions live.
Faits, limites et références (5)
Limite : Périmètre transactionnel Merchant ou Affiliate Full + Booking autorisé ; ne pas confondre cette Partner API avec la Supplier API.
À demander : Identifier le mode du produit avant de choisir le message de confirmation.
Viator distingue l’ingestion des produits et des disponibilités de leur interrogation en temps réel. Les parcours paginés documentés utilisent un curseur de continuation, notamment nextCursor.
Portée : Documentation de distribution Viator ; les endpoints et droits utilisables dépendent du niveau d’accès accordé au partenaire. Aucune fréquence de synchronisation universelle déduite.
Basic et Full Affiliate renvoient la transaction vers viator.com. Full + Booking permet la transaction sur le site partenaire, après autorisation ; dans ce montage affilié, Viator reste merchant of record.
Portée : Périmètre Affiliate décrit sur cette page ; ne pas le confondre avec une offre Merchant ou la certification d’un compte.
Pour les partenaires Merchant, le circuit prévoit un accusé dans les cinq minutes suivant l’annulation ; à défaut, Viator envoie un email au contact support enregistré. L’accusé de modified-since/acknowledge concerne uniquement eventType CANCELLATION. Un HTTP 200 sans corps constitue une réussite de cet accusé. Les partenaires Affiliate avec accès Booking ne doivent pas utiliser cette opération d’accusé ; leur contrat prévoit l’information du client par Viator.
Portée : Périmètre du circuit Viator documenté, vérifié le 23 octobre 2026. Un accusé ne prouve ni lecture client ni rapprochement financier.
Pour UNIT, Viator distingue type d’unité, catégorie TRAVELER et bornes de voyageurs. La documentation limite actuellement chaque réservation à une unité.
Portée : Périmètre Viator Partner API consulté le 23 octobre 2026. Les capacités se lisent dans le produit courant ; l’unité tarifaire ne prouve ni l’exclusivité ni l’acceptation d’une réservation.
Contrôles proposés pour ce périmètre
Trois modes
À réunir : confirmationType distingue INSTANT, MANUAL et INSTANT_THEN_MANUAL.. Identifier le mode du produit avant de choisir le message de confirmation.
Attente limitée
À réunir : Une demande manuelle non traitée est rejetée après 72 heures ou à l’atteinte de sa limite de réservation, si celle-ci arrive avant.. Ne pas présenter 72 heures comme un délai toujours disponible.
Paiement et billet
À réunir : Le parcours manuel prévoit la facturation après confirmation et le voucher seulement une fois la réservation confirmée.. Distinguer préautorisation, paiement et document disponible, prestation par prestation.
Viator décrit les métadonnées des questions : identifiant, type, groupe, unités et caractère obligatoire. Certaines réponses sont attendues pour chaque voyageur.
Groupe de question
Distinguer PER_TRAVELER et question de dossier.
Type de réponse
Valider le format demandé sans transformer le sens.
Unité
Rapprocher la valeur de l’unité admise pour NUMBER_AND_UNIT.
Scénario proposé : Tester une question obligatoire par participant avec deux voyageurs et une réponse numérique utilisant une mauvaise unité.
Portée : Questions variables selon le produit ; limiter la collecte aux données effectivement requises.
Contrôles éditoriaux proposés, à rejouer sur votre périmètre ; aucun appel à une API fournisseur ni test de réservation effectué.
Basic fournit des informations synthétiques ; Reading ajoute options et disponibilités. Masterbill permet de réserver avec facturation mensuelle et place le partenaire dans le rôle de merchant of record, selon le montage décrit.
Pour quel besoin ? Distributeur qui peut satisfaire les conditions d’accès correspondant au niveau d’intégration visé.
Test conseillé : Faire confirmer le niveau accessible avant développement ; contrôler ensuite options, prix, créneaux et responsabilité de la vente.
En savoir plus
Autres points à examiner
À cibler pour médias voyage, apps destination et acteurs avec audience significative.
Les niveaux d’accès varient selon trafic, capacité technique et potentiel partenaire.
Faits, limites et références (4)
Limite : API partenaire de distribution, article mis à jour le 4 septembre 2026 et relu le 1er novembre 2026. Les critères publiés ne valent pas acceptation d’un compte et ces niveaux ne décrivent pas les opérations de la Supplier API.
À demander : Quel niveau, contrat et rôle commercial votre responsable partenaire confirme-t-il ?
Dans le parcours Supplier API, reserve constitue une étape précédant book. La documentation décrit une référence de réservation et une expiration, puis la confirmation de la réserve ; elle demande aussi de traiter les répétitions sans créer une autre réservation pour la même demande.
Portée : Endpoints à implémenter côté fournisseur ou intégrateur. Ce parcours ne décrit pas une API de catalogue pour revendeurs ; les fonctions et règles doivent être confirmées pour la connexion concernée.
GetYourGuide crée une nouvelle réserve puis une réservation avec la même référence GYG, mais des données modifiées. L’intégrateur doit détecter les données modifiées et retourner une nouvelle réservation. Après réussite de la nouvelle réservation, GetYourGuide demande l’annulation avec l’ancienne référence de réservation fournisseur.
Portée : Parcours Supplier API lorsque le client demande une modification à GetYourGuide ; distinct des droits de l’API partenaire de distribution.
Dans le rapport partenaire, Traveler origin est le pays de l’adresse de facturation. Booking date et Travel date distinguent réservation et participation ; Participants est un effectif, distinct du nombre de réservations.
Portée : Rapport du programme partenaire de distribution, mis à jour le 11 décembre 2024. Ces champs ne décrivent ni la nationalité des visiteurs ni le schéma de la Supplier API.
Contrôles proposés pour ce périmètre
Accès
À réunir : Niveau et critères confirmés. Ne pas déduire un droit de réservation d’un accès Reading.
Contenu
À réunir : Produit, option et disponibilité. Rapprocher le détail proposé de l’option réellement consultée.
Montage
À réunir : Contrat et rôle de marchand. Faire attribuer encaissement, facturation et relation client.
Activation
À réunir : Périmètre accepté et essais. Vérifier les conditions de passage en production du compte.
Basic et Reading
À réunir : Basic : au moins 100 000 visites mensuelles pour un site ou 50 000 téléchargements au total pour une application. Reading : un million de visites mensuelles ; l’article demande aussi 300 réservations mensuelles aux partenaires déjà en Basic.. Conserver l’unité et la période de chaque critère ; ne pas comparer téléchargements cumulés et visites mensuelles comme un même indicateur.
Masterbill
À réunir : Le tableau indique une offre proposée par les Partnership Managers, avec dépôt et contrat spécifique ; le partenaire agit comme merchant of record avec facturation mensuelle.. Faire confirmer critères et montage contractuel avant de présenter ce niveau comme accessible à toute intégration.
L’existence d’une documentation de vols ne prouve pas que votre entreprise peut ouvrir un compte, émettre un billet ou traiter une modification. Comparez d’abord le mode d’accès et les responsabilités après la vente.
Trois API hôtelières peuvent fournir des offres tout en imposant des étapes et conditions d’accès différentes. Le bon comparatif suit une même chambre, une même occupation et le même service après réservation.
Une réservation intégrée peut exister dans un modèle affilié. À l’inverse, un standard ouvert ne donne aucun catalogue commercial : niveau d’accès, lieu de transaction et responsabilité doivent être lus séparément.
Une fiche hôtel fiable relie un établissement identifié, des chambres décrites précisément et des conditions qui restent attachées au tarif choisi. Voici les champs à contrôler avant d’importer ou de publier une offre.
La description d’une activité doit permettre de choisir le bon produit et de rejoindre le bon accueil. Contrôlez ensemble option, horaire, participants, inclusions et document d’accès.
Un itinéraire aérien devient comparable quand horaires, aéroports, voyageurs, bagages et conditions appartiennent à la même offre. Cette fiche aide à vérifier ce que le client accepte réellement avant de payer.
Le répertoire aide à identifier le marché. La décision finale doit rester fondée sur vos cas d’usage, vos responsabilités et vos conditions contractuelles.
Comment choisir une solution B2B pour le tourisme ?
Définissez un besoin prioritaire, filtrez par métier et mode d’accès, puis retenez trois à cinq acteurs. Comparez-les sur un même scénario en intégrant les coûts de mise en place, de paiement, de support, de maintenance et de sortie.
Combien de solutions faut-il présélectionner ?
Une présélection de trois à cinq solutions permet généralement d’organiser des démonstrations approfondies sans diluer la comparaison. Utilisez le même scénario, les mêmes volumes et les mêmes cas d’après-vente pour chaque fournisseur.
La présence dans le répertoire vaut-elle recommandation ?
Non. Le répertoire est un outil de recherche éditorial. La présence d’un acteur ne vaut ni certification ni recommandation commerciale. Les fonctionnalités, tarifs, pays couverts et conditions d’accès doivent être confirmés auprès de la source officielle.
Examiner un produit sur pièces
Des dossiers pour préparer vos essais
Les fonctions documentées sont séparées des contrôles que nous proposons. Chaque dossier conserve ses sources et sa date de consultation.
