595 solutions pour construire votre écosystème B2B tourisme.

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.

Documentation principale · consultée le 31/10/2026

Autres références pour ce périmètre

• Viator : managing product and availability data · consultation du 11/10/2026

  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.

• Viator : niveaux Affiliate et Full + Booking · consultation du 18/10/2026

  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.

• Viator — Automating supplier cancellations and amendments · consultation du 23/10/2026

  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.

• Viator — Calculating Product Pricing · consultation du 23/10/2026

  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.

Données et contrôles d’intégration

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é.

Questions de réservation structurées · consultation du 13/10/2026

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 ?

Documentation principale · consultée le 01/11/2026

Autres références pour ce périmètre

• GetYourGuide : Supplier API endpoints · consultation du 11/10/2026

  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 Integrator Portal — Booking Change · consultation du 22/10/2026

  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.

• GetYourGuide — Bookings report 101 · consultation du 22/10/2026

  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.

Faits, limites et références (1)

Limite : Ces modes ne donnent pas automatiquement les mêmes responsabilités, données ou opérations. Une page de collaboration générale ne vaut pas activation de tous les accès pour un compte.

À demander : Quel modèle est retenu pour notre activité, qui confirme et assiste le voyageur, et quels outils sont autorisés dans ce modèle ?

Documentation principale · consultée le 08/10/2026

Faits, limites et références (1)

Limite : Périmètre annoncé par la documentation ; droits distributeur et conditions de chaque produit restent à confirmer. Aucun billet ni remboursement réel testé.

À demander : Un endpoint d’annulation garantit-il un remboursement ?

Documentation principale · consultée le 10/10/2026

Données et contrôles d’intégration

La documentation sépare catalogue, disponibilité et prix, cycle de réservation et notifications de changement.

Produit

Rapprocher la fiche et l’identifiant du catalogue.

Disponibilité

Dater le contrôle du créneau et du prix retenus.

Changement

Prévoir une preuve de confirmation ou d’annulation reçue.

Scénario proposé : Faire suivre une activité du catalogue à son annulation et comparer chaque état affiché au résultat du parcours testé.

Portée : Champs de contrôle proposés par la rédaction ; cet aperçu ne fixe pas les noms d’API ni les délais de confirmation.

Contrôles éditoriaux proposés, à rejouer sur votre périmètre ; aucun appel à une API fournisseur ni test de réservation effectué.

Catalogue, disponibilité et cycle de réservation · consultation du 13/10/2026

Faits, limites et références (3)

Limite : Redirection hébergée, distincte de la création via External API ; affiliation et droits de connexion restent nécessaires.

À demander : Comment conserver créneau, quantités et attribution lorsqu’un visiteur reprend son choix dans le checkout ?

Documentation principale · consultée le 22/10/2026

Autres références pour ce périmètre

• FareHarbor : Booking Overlay Links · consultation du 11/10/2026

  FareHarbor documente des liens vers son interface de réservation hébergée pour une société, un produit et une disponibilité. Des paramètres peuvent préremplir l’attribution et les quantités ; ctrs utilise les identifiants de tarifs du créneau ciblé.

  Portée : Parcours de redirection, distinct de la création par External API. L’attribution nécessite une affiliation valable ; le montage FHDN applicable doit être confirmé avant exploitation.

• FareHarbor : distinguer inscription, alerte et réservation · consultation du 22/10/2026

  L’inscription en ligne déclenche toujours un courriel ; l’envoi après ajout manuel est configurable et désactivé par défaut. Une annulation ou un changement peut déclencher l’alerte après un délai configuré, si la place correspond au type de client. Un client déjà averti automatiquement ne reçoit plus d’autre alerte automatique pour ce créneau. Book now peut ensuite conduire à un créneau redevenu complet. Un cutoff ou le paramètre bookable-only=yes du lien d’intégration peut masquer l’option.

  Portée : Aide FareHarbor mise à jour le 29 septembre 2026. Les types conditionnels, dont enfant exigeant un adulte, ne fonctionnent pas dans Waitlist. Fonction du logiciel décrite ici ; aucun accès API supplémentaire n’est déduit.

Contrôles proposés pour ce périmètre

Destination

À réunir : Cas fictif : produit I8, disponibilité A8 remplacée par A9. Vérifier les trois niveaux du lien et les tarifs propres à la nouvelle disponibilité.

Quantités

À réunir : Deux adultes et un enfant, avec références de tarifs de A9. Comparer le formulaire ouvert au choix initial ; ne pas réutiliser les anciennes références par ressemblance.

Attribution

À réunir : Référence partenaire P8 et affiliation à faire confirmer. Retrouver le rattachement autorisé sans considérer le simple ajout d’un paramètre comme un accord commercial.

Résultat

À réunir : Checkout ouvert puis abandonné avant confirmation. Ne pas marquer une réservation comme créée dans le système d’origine sur la seule ouverture du lien.

Faits, limites et références (1)

Limite : Parcours RezdyConnect, à distinguer de la référence de l’API publique Rezdy. La page présente des formulations différentes sur la méthode d’annulation ; faire confirmer le contrat d’opération plutôt que prescrire un verbe HTTP ici.

À demander : Un panier en traitement vaut-il confirmation ?

Documentation principale · consultée le 11/10/2026

Données et contrôles d’intégration

RezdyConnect distingue les étapes réservation, booking et cancellation. La référence orderNumber est réutilisée dans les demandes ultérieures.

Référence

Conserver orderNumber unique et stable.

État

Distinguer PROCESSING, CONFIRMED et annulation.

Ordre des éléments

Préserver la correspondance des prestations et participants.

Scénario proposé : Faire suivre une réservation provisoire jusqu’à sa confirmation puis son annulation sans créer une seconde référence locale.

Portée : Référence de RezdyConnect ; ne généralise pas les noms ou méthodes à toutes les intégrations Rezdy.

Contrôles éditoriaux proposés, à rejouer sur votre périmètre ; aucun appel à une API fournisseur ni test de réservation effectué.

Réservation, confirmation et annulation · consultation du 13/10/2026

Faits, limites et références (1)

Documenté : Le portail distingue API de réservation, produits, channel manager, webhooks et implémentation OCTO.

Limite : Une capacité documentée exige un mapping produit et une implémentation compatibles chez le partenaire.

À demander : Quels identifiants, variantes et capacités sont synchronisés sur notre connexion ?

Documentation principale · consultée le 01/10/2026

Données et contrôles d’intégration

La référence Bókun distingue disponibilité de l’expérience et statistiques de disponibilité réservées au fournisseur, incluant des états absents de la première réponse.

Produit

Rapprocher experienceId de l’expérience suivie.

Vue disponible

Distinguer disponibilité vendable et vue statistique.

Droit du compte

Documenter le rôle autorisant l’accès aux statistiques.

Scénario proposé : Faire examiner un créneau complet absent d’une vue vendable et présent dans les statistiques autorisées.

Portée : Absence d’un créneau dans une réponse ne vaut pas suppression du produit ; droits et version à vérifier.

Contrôles éditoriaux proposés, à rejouer sur votre périmètre ; aucun appel à une API fournisseur ni test de réservation effectué.

Disponibilité vendable et statistiques · consultation du 13/10/2026

Faits, limites et références (4)

Limite : Le standard ne constitue pas un catalogue vendable et ne prouve pas l’activation de toutes les fonctions pour un revendeur.

À demander : Conserver produit, option et disponibilité sélectionnés dans le même contexte.

Documentation principale · consultée le 31/10/2026

Autres références pour ce périmètre

• OCTO : spécification et documentation · consultation du 05/10/2026

  OCTO est une spécification ouverte d’échange pour les activités et attractions, avec un socle et des capacités complémentaires.

• OCTO : socle et capacités optionnelles · consultation du 18/10/2026

  OCTO distingue endpoints du socle et capacités optionnelles, notamment contenu, prix et prises en charge. La création d’une réservation peut retenir la disponibilité en ON_HOLD avant confirmation ou expiration.

  Portée : Spécification d’échange : capacités réellement implémentées et activation commerciale du partenaire à vérifier.

• OCTO — Pricing capability · consultation du 22/10/2026

  pricingPer vaut UNIT ou BOOKING. En mode BOOKING, le prix s’applique une fois à la réservation plutôt qu’à chaque unité achetée. Le suffixe From, comme pricingFrom, indique un prix indicatif et non final. retail est le prix de vente au client ; net est le montant de gros facturé par le fournisseur. Le montant entier se divise par 10 à la puissance currencyPrecision pour obtenir le montant décimal.

  Portée : Capacité optionnelle pricing, à demander dans Octo-Capabilities. Le standard ne prouve pas son activation chez chaque fournisseur.

Contrôles proposés pour ce périmètre

availabilityId

À réunir : Un contrôle de disponibilité fournit la référence nécessaire à la création de la réservation.. Conserver produit, option et disponibilité sélectionnés dans le même contexte.

ON_HOLD

À réunir : La création retient la capacité jusqu’à confirmation ou expiration ; la durée demandée est bornée par le fournisseur ou son prestataire OCTO.. Lire l’échéance retournée au lieu de supposer une durée universelle de retenue.

Confirmation

À réunir : Une réservation retenue peut être confirmée tant qu’elle n’a pas expiré.. Vérifier le statut retourné avant de présenter la prestation comme confirmée.

Annulation

À réunir : Le parcours documente POST /bookings/{uuid}/cancel, distinct d’une suppression HTTP DELETE.. Suivre le contrat de l’opération et ses conditions d’annulation.