API transferts et parcours partenaire
Booking.com Transfers : distinguer recherche et reporting
La recherche de transferts peut enrichir un itinéraire sans créer la réservation dans votre interface. Le produit documenté distingue recherche avec redirection et reporting des commandes. Le projet doit expliquer ce que le voyageur termine sur Booking.com et ce que le partenaire peut retrouver ensuite.
Sources consultées le · Méthode éditoriale de Performance Voyage
Quel rôle dans votre organisation ?
Faites confirmer accès, versions et opérations autorisées avant de construire le parcours. Définissez aussi la frontière de support après redirection : l’équipe doit savoir où la réservation est terminée et quels objets permettent le rapprochement. N’attribuez pas au parcours une création de commande intégrée ou une couverture géographique non confirmée.
Booking.com Transfers API (bêta) figure dans la famille Mobilité et transports. Les prix, pays couverts, niveaux de service et droits du compte ne sont pas certifiés par ce dossier. Faites-les préciser dans une proposition datée.
Source officielle de l’entrée ↗ · Retrouver la fiche du répertoire
Ce que les sources documentent
Booking.com : périmètre transferts
La documentation présente Search, look and redirect en bêta pour partenaires approuvés, et reporting de transferts via Orders en version 3.2.
Consulter la source 1 ↗Booking.com : rapports Orders v3.2
Orders fournit des données de reporting et rapprochement des commandes ; le suivi doit distinguer objets de commande et prestations ou trajets concernés.
Consulter la source 2 ↗La suite propose nos contrôles de sélection : elle ne décrit pas des tests exécutés sur un compte fournisseur. Une documentation peut évoluer ; relisez la version applicable avant de développer ou de signer.
Quatre ensembles de données à rapprocher
| Ensemble | À collecter | Contrôle proposé |
|---|---|---|
| Recherche | Lieux, dates, passagers, devise et pays | Rejouer les critères sans réutiliser une ancienne réponse après modification. |
| Véhicule | Capacité, bagages, prix et conditions | Comparer des offres qui répondent à la même demande. |
| Redirection | Offre retenue et passage au vendeur | Rendre la suite et le vendeur compréhensibles pour le voyageur. |
| Suivi | Commande et trajets individuels | Relier aller et retour sans assimiler un statut agrégé à chaque trajet. |
Conservez identifiant, source, date et résultat dans le registre de comparaison. Travaillez avec des données anonymisées et les accès de test autorisés.
Un scénario à faire rejouer pendant le pilote
Préparez un aller-retour aéroport avec plusieurs passagers et bagages, puis modifiez l’heure ou le nombre de voyageurs avant redirection. Vérifiez les offres présentées et la suite sur le site du vendeur dans le périmètre de test autorisé. Pour le reporting, examinez un exemple de commande à plusieurs trajets et faites expliquer les références et états à lire pour chacun.
Le voyageur comprend où il finalise la réservation. Les critères et capacités restent cohérents avec sa demande, et l’équipe distingue résultat de recherche, commande et trajets suivis. Les accès bêta et les opérations de reporting sont identifiés avec leur version et leurs limites.
Préparez les mêmes exemples pour les autres acteurs de la catégorie Mobilité et transports. Comparez les responsabilités et les preuves sur votre tâche, avec la grille d’évaluation et le coût complet.
Définir les responsabilités et les conditions de fonctionnement
Préparer la frontière entre recherche et vente
Offres
Intervenants à associer : Produit et catalogue
Vérifier critères, capacités et explication de la suite.
Passage
Intervenants à associer : Intégration et partenariat
Conserver redirection et périmètre d’accès obtenu.
Reporting
Intervenants à associer : Support et finance
Lire commande et trajets avec leur version et leurs états.
Comparer le coût du parcours réellement exploité
Le coût comprend recherche, maintenance du périmètre bêta et rapprochement des rapports autorisés. Une redirection réussie ne représente pas automatiquement une commande attribuée. Comparez les événements réellement disponibles et la charge d’aide au voyageur, sans compléter les étapes invisibles par une vente supposée.
Préparer la continuité des dossiers ouverts
Lors d’une évolution d’accès ou de version, gardez les références de commandes et trajets déjà suivis. Distinguez arrêt de nouvelles recherches et continuité du reporting. Les voyageurs doivent conserver le contact du vendeur de leur réservation.
Erreurs à éviter dans la comparaison
- Présenter la recherche comme une réservation déjà créée.
- Déduire l’état de chaque trajet du seul état de commande.
- Publier une capacité ou un prix sans relire les critères de la demande.
Marquez un point non démontré comme « à confirmer ». Il reste distinct d’un échec observé et d’une fonction annoncée. Une décision fiable peut retenir un périmètre plus restreint si les responsabilités et la reprise sont maîtrisées.
Conserver les résultats du pilote
Utiliser la fiche de contrôle de ce parcours et le registre de recette associé. Garder les résultats observés distincts des points à confirmer et attribuer les suites aux intervenants concernés.
Questions fréquentes
La recherche de transferts est-elle ouverte à tous les comptes ?
La documentation la présente en bêta pour partenaires approuvés. Faites confirmer les droits et la version nécessaires avant intégration.
Le reporting implique-t-il une réservation créée dans votre site ?
Le flux décrit finalise la réservation après redirection. Le reporting sert ensuite au suivi dans son périmètre, sans prouver une création intégrée.
Comment suivre un aller-retour ?
Conservez la commande et les objets de chaque trajet. Les états agrégés ne doivent pas masquer une différence de traitement entre les deux parties.
Quel résultat suivre après la redirection ?
Utilisez les objets de reporting ouverts à votre compte et leur définition. Distinguez visite sortante, commande et état de chaque trajet, avec les limites des étapes non observées.