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.
34solutions correspondantes
Air / plateformeAPI
Trawex
Trawex présente des moteurs de réservation, des API voyage et des services de développement destinés aux agences, distributeurs et entreprises travel tech.
Pour quel besoin ? Projet qui veut réunir recherche, réservation et administration dans un environnement configurable.
Test conseillé : Construire un voyage à deux prestations et vérifier prix final, documents et reprise du dossier en back-office.
En savoir plus
Faits, limites et références (1)
Limite : Le catalogue de services ne décrit pas les droits accordés sur chaque fournisseur ni les fonctions de votre réalisation. Séparez contrat logiciel, accès au contenu et travail spécifique.
À demander : Quelles opérations et sources seraient livrées dans le premier lot, avec quelles preuves de réservation et responsabilités après la vente ?
La documentation partenaire Musement distingue API de vente d’activités, marque blanche, rattachement de réservations et widgets de promotion.
Pour quel besoin ? Distributeur qui veut intégrer des activités avec un degré de contrôle adapté à son rôle dans la réservation et le paiement.
Test conseillé : Comparer les deux parcours sur disponibilité, commande, paiement, billet, annulation et responsabilités du support.
En savoir plus
Faits, limites et références (1)
Limite : Ces modèles ne confient pas les mêmes opérations au partenaire ; accès, vendeur final, paiement et support doivent être identifiés pour l’option retenue.
À demander : Quel modèle donne les opérations nécessaires à notre rôle et où les réservations et remboursements sont-ils suivis ?
Anixe présente notamment Resfinity pour le sourcing hôtelier, des solutions de cache de prix et disponibilités, et des fonctions de mapping d’hôtels, chambres et pensions.
Pour quel besoin ? Voyagiste ou distributeur qui agrège plusieurs sources hôtelières et doit normaliser son catalogue.
Test conseillé : Comparer les résultats de deux fournisseurs pour un même hôtel, puis vérifier chambre, repas, prix et fraîcheur du tarif.
En savoir plus
Faits, limites et références (1)
Limite : Ces fonctions répondent à des étapes différentes. Un résultat mis en cache ou rapproché par mapping doit encore être validé pour l’offre et la réservation demandées.
À demander : Comment un résultat de cache est-il revalidé, et quelles preuves justifient un rapprochement hôtel, chambre et pension entre sources ?
La documentation PaxFaB décrit le produit d’agrégation de Paxport et une API XML pour rechercher, chiffrer et réserver du contenu voyage ; elle distingue guides métier, références, schémas et gestion des changements d’API.
Pour quel besoin ? Intégrateur qui veut relier un moteur de réservation aux offres aériennes et à leur suivi.
Test conseillé : Contrôler variation de prix entre recherche et paiement, puis disponibilité des opérations après vente.
En savoir plus
Faits, limites et références (1)
Limite : La documentation publique ne définit pas les fournisseurs et opérations activés dans un contrat. Une réponse de recherche ne prouve pas la réussite du prix final ou de la réservation.
À demander : Quels fournisseurs, versions et opérations sont activés, et comment recherche, chiffrage, panier et confirmation restent-ils reliés ?
Technoheaven présente des logiciels et portails destinés aux entreprises de voyage, avec des offres B2B et B2C et des connexions à des fournisseurs.
Pour quel besoin ? Entreprise qui souhaite assembler portail B2B, moteur de réservation et intégrations fournisseurs.
Test conseillé : Vérifier la profondeur réelle de chaque intégration et le traitement d’un dossier après réservation.
En savoir plus
Faits, limites et références (1)
Limite : Une liste de connecteurs ne décrit pas les contenus ouverts par vos contrats ni l’étendue du développement spécifique. La couverture doit être établie par opération et produit dans le projet proposé.
À demander : Quels parcours seront livrés et testés pour recherche, réservation, modifications et exports, avec quelle répartition des tâches entre éditeur et agence ?
Orchestra présente une plateforme travel tech pour la vente de voyages, avec notamment gestion administrative des dossiers, modification, enrichissement, annulation et solutions de back-office et comptabilité.
Pour quel besoin ? Voyagiste qui combine stocks, règles commerciales et plusieurs canaux de distribution.
Test conseillé : Créer un forfait, modifier une prestation et tracer prix, documents et notifications de bout en bout.
En savoir plus
Faits, limites et références (1)
Limite : Les modules et connexions doivent être qualifiés dans l’offre retenue ; un back-office ne prouve pas chaque opération disponible chez tous les fournisseurs.
À demander : Quels objets et versions relient proposition, dossier, réservation et comptabilité dans le périmètre proposé ?
Revelex présente des solutions de technologie et de réservation voyage couvrant notamment croisières, hébergements, vols et voitures, avec plusieurs modalités d’hébergement du logiciel.
Pour quel besoin ? Distributeur qui cherche un parcours de vente couvrant plusieurs prestations et canaux.
Test conseillé : Faire démontrer un dossier multi-produit avec modification, commission et document client.
En savoir plus
Faits, limites et références (1)
Limite : La présence d’un type de produit au catalogue n’établit pas l’accès aux mêmes fournisseurs et opérations pour chaque agence. Les engagements d’hébergement et de support sont aussi à comparer séparément.
À demander : Quelle configuration couvre nos ventes et qui conserve la capacité de servir les dossiers ouverts lors d’une évolution du logiciel ?
TripCreator présente création, chiffrage, vente et exploitation du voyage ; le site distingue les accès V2 et V3 et propose une relecture des champs avant création à partir d’un document importé.
Pour quel besoin ? Créateur de séjours sur mesure qui veut relier proposition commerciale et exécution.
Test conseillé : Transformer un itinéraire en réservation puis modifier une étape sans perdre prix ni documents.
En savoir plus
Faits, limites et références (1)
Limite : Une extraction assistée ne vaut pas validation du produit ; la version, les modules et les conditions commerciales des prestations restent à contrôler.
À demander : Quelle version utilisons-nous et quelles validations empêchent une donnée importée incorrecte d’atteindre le devis ou la facture ?
mTrip présente itinéraires, documents et application mobile sous la marque du distributeur, avec diffusion par app, web ou PDF ; la gestion des risques est annoncée comme option.
Pour quel besoin ? Acteur qui veut fournir un programme mobile de marque avec informations de voyage à jour.
Test conseillé : Changer une prestation après téléchargement et vérifier notification, mode hors ligne et nouvelle version.
En savoir plus
Faits, limites et références (1)
Limite : Un document ou une notification ne constitue pas un titre de transport ; l’option de gestion des risques n’est pas nécessairement incluse.
À demander : Comment sont distingués document de voyage, billet fournisseur, ajout manuel et état d’une prestation modifiée ?
Vibe présente une plateforme de réservation pour agences loisirs, OTA et TMC, avec un socle partagé entre besoins de loisirs et voyages d’affaires.
Pour quel besoin ? Agence ou voyagiste qui veut construire un parcours de vente connecté à plusieurs sources.
Test conseillé : Créer un dossier multi-prestations et suivre les changements de prix, la confirmation et les documents.
En savoir plus
Faits, limites et références (1)
Limite : Un socle partagé ne garantit pas les mêmes accords ou fonctions pour chaque clientèle ; contenu, politiques et servicing doivent être vérifiés sur le compte.
À demander : Quelles opérations sont ouvertes à l’agent et au voyageur dans nos produits, et comment une exception est-elle reprise ?
Cangooroo présente un moteur de réservation SaaS réunissant plusieurs familles de prestations touristiques, avec configuration des prix, politiques et échéances. Le site indique son appartenance au groupe Juniper.
Pour quel besoin ? Vendeur qui doit gérer contenu, prix et commandes de plusieurs fournisseurs.
Test conseillé : Suivre un produit de l’import jusqu’au voucher, puis tester une annulation.
En savoir plus
Faits, limites et références (1)
Limite : L’agrégation du catalogue ne suffit pas à définir vendeur, stock garanti et circuit après-vente. Les règles commerciales doivent être rapprochées de celles de chaque source de produit.
À demander : Comment retrouver le tarif source, la règle de vente appliquée et les références de chaque prestation dans un dossier combiné ?
Serko présente GetThere pour les programmes de voyages d’entreprise, avec des offres filtrées et évaluées selon les préférences et politiques du programme.
Pour quel besoin ? Grande entreprise ou TMC qui doit appliquer plusieurs règles de voyage dans une expérience de réservation commune.
Test conseillé : Configurer deux politiques et fournisseurs préférés, puis comparer les résultats et le traitement d’une modification.
En savoir plus
Faits, limites et références (1)
Limite : La présentation de l’outil ne confirme ni la configuration d’une entreprise ni toutes les prestations et procédures d’assistance de sa TMC.
À demander : Comment une exception de politique est-elle approuvée puis suivie jusqu’au service après-vente ?
HTS décrit Stays comme un parcours de réservation d’hébergement sous la marque du partenaire, intégré à ses environnements numériques, de fidélité et de relation client.
Pour quel besoin ? Plateforme voyage qui souhaite ajouter l’hébergement à son produit sans construire tout le socle hôtelier.
Test conseillé : Vérifier correspondance des chambres, présentation des conditions et traitement d’une annulation après paiement.
En savoir plus
Faits, limites et références (1)
Limite : Une interface en marque blanche et une API hôtelière sont deux produits à distinguer. La présentation ne garantit pas les mêmes capacités de personnalisation, contenus ou responsabilités de service pour tous les partenaires.
À demander : Qui contrôle l’interface, les comptes client, le paiement et les demandes après réservation dans notre proposition Stays ?
TravelCarma présente un accompagnement de développement et d’évolution de systèmes de voyage, notamment intégration de contenus fournisseurs, GDS et NDC dans des environnements existants.
Pour quel besoin ? Agence ou voyagiste souhaitant vendre plusieurs produits depuis une interface commune.
Test conseillé : Assembler deux prestations puis contrôler taxe, devise, paiement et documents client.
En savoir plus
Faits, limites et références (1)
Limite : Une prestation sur mesure ne doit pas être décrite comme un catalogue de modules tous disponibles sans cadrage. Les engagements portent sur une architecture, des interfaces et un périmètre convenus.
À demander : Quels composants sont livrés, qui possède et maintient les interfaces et quelles opérations sont incluses dans la recette et le support ?
Lecture automatique interrompue · contrôle du 31/10/2026 · Portée du contrôle
eSIM / modèles partenairesaffiliation
BNESIM
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 ?
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é.
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.
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 ?
TrekkSoft présente un logiciel de réservation pour opérateurs de visites et activités, avec des connexions de distribution vers des OTA et places de marché.
Pour quel besoin ? Opérateur qui vend à la fois sur son site et sur place et veut éviter des capacités divergentes entre ces points de vente.
Test conseillé : Vendre un créneau en ligne puis au comptoir, fermer la dernière place et vérifier billets, paiement, accueil et statut chez les revendeurs.
En savoir plus
Autres points à examiner
Bon choix pour digitaliser un opérateur ou DMC avant de connecter des canaux externes.
À comparer avec FareHarbor, Rezdy et Bókun selon pays, coûts et connecteurs.
Faits, limites et références (1)
Limite : Une synchronisation annoncée ne garantit pas toutes les règles de capacité ni les mêmes connexions dans chaque offre. Les catégories, créneaux et changements doivent être testés sur les canaux retenus.
À demander : Quelle réservation simultanée prouve la bonne consommation des places, puis leur traitement après modification ou annulation ?
CarTrawler décrit des choix d’intégration comprenant moteur sous la marque du partenaire, insertion dans le parcours, portail client et API pour un parcours de location conçu par le partenaire.
Pour quel besoin ? Compagnie ou vendeur de voyages qui veut proposer une solution de mobilité avant ou après le trajet principal.
Test conseillé : Comparer la prise en charge en aéroport, les conditions du fournisseur, le paiement et le parcours d’assistance en cas de retard.
En savoir plus
Autres points à examiner
À regarder pour ajouter une brique car rental ou mobilité à un parcours travel.
Endpoint staging puis production avec accompagnement partner manager.
Faits, limites et références (1)
Limite : Ces choix ne sont pas un produit unique aux fonctions interchangeables. Catalogue, personnalisation et service client doivent être précisés dans la combinaison contractée.
À demander : Qui contrôle interface, suivi client et après-vente dans l’option retenue, et quelles opérations sont accessibles par notre API ou moteur ?
Discover Cars présente un programme d’affiliation avec inscription et outils de promotion de locations de voitures, associé à une rémunération des réservations selon les conditions du compte.
Pour quel besoin ? Éditeur de guides routiers ou de destinations qui veut orienter ses lecteurs vers une comparaison de véhicules disponibles.
Test conseillé : Ouvrir une recherche depuis un article, comparer caution et assurance avant paiement et vérifier l’attribution de la réservation.
En savoir plus
Autres points à examiner
Facile à lancer pour guides, blogs et sites de destination.
API pertinente si l’expérience de réservation doit rester dans votre interface.
Faits, limites et références (1)
Limite : Les chiffres promotionnels de rémunération ne constituent pas un revenu garanti. Les outils, intégrations et conditions d’attribution doivent être qualifiés sans confondre affiliation et réservation marchande.
À demander : Quels outils sont activés pour notre compte et quels états relient réservation, annulation, commission validée et paiement ?
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.
