Guide d'intégration

L'API Booking.com : comment fonctionne l'accès, et ce qu'elle permet vraiment

Écrit pour le développeur ou le fondateur technique qu'on a envoyé vers les API de connectivité de Booking.com. On y explique comment fonctionnent la désignation partenaire et la connexion par établissement, le modèle de données dont tout le reste dépend, et les deux ou trois comportements qui font qu'une mise à jour de tarifs Booking.com réussit sur le papier et ne change rien en pratique.

Ce qu'est l'API Booking.com

Les API de Booking.com sont faites pour les fournisseurs de connectivité: les channel managers et les logiciels de gestion qui synchronisent l'hébergement pour le compte de nombreux établissements à la fois. Ce ne sont pas des API grand public, il n'existe aucune surface publique de recherche ou de réservation pour les tiers, et aucun portail développeur auquel s'inscrire.

Concrètement, ce sont plusieurs surfaces produit réunies sous un seul partenariat : disponibilité et tarifs, réservations, configuration des établissements et des chambres, contenu, messagerie, avis et frais. Elles se comportent différemment les unes des autres, sont accordées séparément, et une partie de l'ancienne surface est en XML plutôt qu'en JSON. Si tu viens d'Airbnb, presque aucune de tes hypothèses ne tient.

Comment obtenir l'accès à l'API Booking.com ?

Trois niveaux, accordés par trois acteurs différents, comme pour Airbnb mais sous une autre forme.

1. Booking.com désigne ton entreprise comme fournisseur de connectivité.Tu candidates, tu es évalué sur le plan commercial et technique, et il y a une étape de certification pour les surfaces que tu comptes utiliser. C'est une relation au niveau de l'entreprise qui se compte en mois.
2. Tu reçois les identifiants d'un compte machine.Contrairement aux tokens OAuth par hôte d'Airbnb, un seul compte machine agit pour tous les établissements connectés à toi. Ce seul identifiant, c'est le rayon d'impact de toute ton activité, et ça change la façon de lire les erreurs : vois la note ci-dessous.
3. Chaque établissement te connecte depuis son propre Extranet.L'hôte se connecte à l'Extranet Booking.com, ouvre la liste des fournisseurs de connectivité, cherche ton fournisseur par son nom et clique sur Connecter. Tant qu'il ne l'a pas fait, ton compte machine ne voit pas du tout cet établissement. Il lui faudra aussi son Hotel ID numérique.

Avec Repull, la partie côté hôte est une seule session hébergée à tes couleurs ; l'hôte fait l'étape dans l'Extranet et colle son Hotel ID, et tu récupères une connexion. Le pas-à-pas est dans Connecter Booking.com.

curl -X POST 'https://api.repull.dev/v1/connect/booking' \
  -H 'Authorization: Bearer sk_live_YOUR_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "redirectUrl": "https://yourapp.com/connected" }'

Établissements, chambres et plans tarifaires

Comprends ça et le reste de Booking.com suit. Rate-le et chaque endpoint semble arbitraire.

Booking.com property   "hotel_id": 5432505        ← the building
└── room               "roomBookingId": 543250501 ← what a guest books
    └── rate plan      "rateId": 98765            ← the terms it sells on
        └── price at an occupancy                ← what you actually write

Un établissement, c'est un bâtiment. Les chambres, c'est ce que réservent les voyageurs. Les plans tarifaires sont les conditions commerciales auxquelles une chambre est vendue, et un prix appartient à un tuple (chambre, plan tarifaire, date, occupation), pas à une nuit. Une villa d'une chambre, c'est le cas simple ; un appart-hôtel de vingt logements, c'est un seul établissement avec vingt chambres, et c'est la norme, pas un cas limite.

Le même logement peut aussi apparaître sous plusieurs établissements Booking.com, généralement parce qu'il a été republié au fil du temps, et une chambre qui n'est rattachée à aucune de tes annonces n'appartient à rien : ses réservations n'ont nulle part où atterrir. Rattache les chambres pendant le flux de connexion, pas après.

Puis-je mettre à jour les tarifs via l'API Booking.com ?

Oui, et c'est la surface la plus utilisée de tout le partenariat. Tu écris un prix pour une chambre sur un plan tarifaire, sur une plage de dates, éventuellement avec des restrictions de durée de séjour et d'arrivée dans le même appel.

curl -X PUT 'https://api.repull.dev/v1/channels/booking/availability' \
  -H 'Authorization: Bearer sk_live_YOUR_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "type": "rates",
    "property_id": "1234567",
    "updates": [{
      "roomId": "123456701",
      "rateId": "98765",
      "dateRange": { "start": "2026-11-04", "end": "2026-11-04" },
      "price": 210,
      "currency": "USD",
      "occupancy": 4
    }]
  }'

roomId et rateId viennent de GET /v1/channels/booking/properties/{id}/rooms. Tout le reste de la requête — et il y en a plus que tu ne crois — est dans Mettre à jour les prix Booking.com.

Pourquoi ma mise à jour de prix sur Booking.com n'a rien fait ?

C'est la question qui amène les gens sur cette page, et il y a deux réponses indépendantes. Les deux ressemblent à un succès.

L'occupation fait partie de la clé, ce n'est pas une préférence

Booking.com ne stocke pas “le prix de cette nuit”. Il stocke un prix pour une nuit pour un nombre de personnessur un plan tarifaire. Donc l'occupation que tu envoies décide de quel prix tu écrases. Chaque montant part avec une occupation, que tu l'indiques ou non.

• Indique une occupation au-dessusdu maximum tarifé par le plan, et Booking.com accepte la requête puis écarte le montant sans rien dire. La nuit garde ce qu'elle avait — souvent 0.00— et l'accusé de réception est identique, octet pour octet, à celui d'une écriture réussie.
• Indiques-en une en dessous et tu reçois un 400. Le prix publié ne change pas.
• La capacité de ta propre annonce n'est pasla donnée qui compte. Ce qui compte, c'est le nombre que Booking.com a pour ce plan tarifaire. Relis-le au lieu de le déduire.

Repull résout l'occupation à partir des données de Booking.com pour la paire (chambre, plan tarifaire) quand tu ne l'indiques pas, te renvoie la valeur utilisée et sa provenance, et refuse l'écriture avec un 422quand il ne peut pas la résoudre. Un montant n'est jamais envoyé à l'aveugle.

L'accusé de réception n'est pas une confirmation

Booking.com répond en général à une écriture de tarifs par un accusé de réception sans statut par date. Le corps est littéralement :

{"ok": ""}

Plages de dates, et la nuit que tu perds

En dessous, le XML de disponibilité et de tarifs prend une plage dont la date to n'est pas écrite: c'est une borne exclusive, comme une date de départ exclut la dernière nuit. La plupart des calendriers que tu as déjà intégrés traitent les deux bouts comme des nuits. Donc la lecture naturelle de “du 1er au 7 août”, c'est sept nuits, mais dans la requête il y en a six, et la nuit que tu perds sans t'en rendre compte, c'est la dernière de chaque plage que tu écris.

C'est une conversion d'une ligne et un bug d'une semaine, parce qu'il ne te coûte que la dernière nuit : le calendrier a l'air globalement juste, un contrôle ponctuel passe, et le trou apparaît sous forme de réservation manquée plutôt que d'erreur.

L'inventaire est une écriture à part

Mettre un prix sur une nuit ne l'ouvre pas à la vente, et l'ouvrir ne lui donne pas de prix. Les chambres à vendre et l'arrêt des ventes sont leur propre type de mise à jour ; les envoyer dans une mise à jour de tarifs est refusé plutôt qu'ignoré sans bruit.

# Close a night: zero rooms to sell, stop-sell on
curl -X PUT 'https://api.repull.dev/v1/channels/booking/availability' \
  -H 'Authorization: Bearer sk_live_YOUR_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "type": "availability",
    "property_id": "1234567",
    "updates": [{
      "roomId": "123456701",
      "rateId": "98765",
      "dateRange": { "start": "2026-11-04", "end": "2026-11-04" },
      "availableRooms": 0,
      "closed": true
    }]
  }'

Détails dans Envoyer la disponibilité à Booking.com. Si tu préfères écrire un calendrier une fois et qu'il arrive sur tous les canaux connectés, c'est PUT /v1/availability/{propertyId}, avec PATCH /v1/availability/batch pour de nombreux établissements à la fois.

Les restrictions qui existent, et celles qui n'existent pas

Durée de séjour minimum et maximum (selon la date de séjour et selon la date d'arrivée), arrivée interdite et départ interdit existent bien et se règlent par chambre, plan tarifaire et plage de dates.

Plusieurs restrictions qu'on s'attend à trouver ne figurent tout simplement pas dans la notification acceptée par Booking.com, notamment une durée de séjour exacte à l'arrivée et un délai de réservation minimum ou maximum. Le bon comportement, c'est de les refuser clairement. Une restriction acceptée puis jamais envoyée, c'est le seul échec invisible dans une réponse, donc Repull répond 422 en nommant le champ au lieu de l'abandonner. Vois restriction_not_supported et Durée minimum et restrictions.

Réservations, messagerie, avis et frais

• Réservations: les lister et en accuser réception. L'accusé de réception n'est pas une formalité facultative : les nouvelles réservations restent en file jusqu'à ce que tu les confirmes, et un partenaire qui ne confirme jamais relit sans cesse les mêmes réservations. Réservations.
• Messagerie: lister les conversations et envoyer. Plus limitée que la surface de fils d'Airbnb ; pas de modification, pas de réactions, pas d'état de lecture. Messagerie voyageurs.
• Avis : lister et répondre. Avis.
• Frais et taxes : lecture et écriture. Frais et taxes.
• Configuration et mise en ligne: créer l'entité juridique, vérifier que tout est prêt, définir les contacts et les règles, et ouvrir un établissement à la vente. Configuration et mise en ligne.
• Pas de modifications.Booking.com n'a pas d'équivalent au flux de modification d'Airbnb. Les changements de dates et de prix sur une réservation existante ne sont pas une opération de l'API.

La matrice des capacitésmet Airbnb et Booking.com côte à côte, et indique le partiel comme partiel au lieu de l'arrondir.

Pourquoi l'API Content renvoie 403 ?

Parce que le contenu est une surface produit à part, avec son propre droit d'accès et son propre chemin de base, séparée de la disponibilité, des tarifs et des réservations. Un établissement peut être entièrement actif — recevoir des réservations, accepter toutes tes écritures de tarifs et de disponibilité — pendant que chaque appel de contenu pour ce même établissement répond 403.

Quand ça arrive, le réflexe est de soupçonner le token, puis l'id de l'établissement, puis les droits de l'hôte dans l'Extranet. Ce n'est en général rien de tout ça. La capacité ne t'a pas été accordée pour cette surface, et reconnecter n'y change rien. Confirme quelles capacités ton partenariat inclut vraiment avant d'inscrire la gestion des photos ou des descriptions dans une version.

Le contenu, quand il est disponible, couvre les photos, les descriptions, les équipements, les services et les règles, au niveau de l'établissement ou de la chambre, et Booking.com relit les changements de texte avant de les publier, donc une écriture est le début d'un processus, pas la fin. Contenu et photos.

Ce que coûte une intégration maison

1. Désignation partenaire et certification. Des mois, avec un examen commercial et une certification technique par surface. Tu ne peux promettre aucune date à un client.
2. Un modèle de sécurité à identifiant partagé.Un seul compte machine pour tous les établissements que tu sers. Rotation, stockage, et un classificateur d'erreurs assez soigné pour qu'un 401 global pendant une panne ne déconnecte pas tous tes clients d'un coup.
3. Le modèle et le rattachement.Des établissements aux chambres, aux plans tarifaires et à tes propres annonces, y compris les établissements à plusieurs chambres, les logements republiés et les chambres non rattachées dont les réservations n'ont nulle part où aller.
4. La vérification des écritures.Comme l'accusé de réception ne prouve rien, une intégration correcte relit et réconcilie. C'est un appel de plus, un délai de stabilisation et une machine à états, sur ton chemin le plus chaud.
5. Des conventions qui ne collent pas.Bornes de dates exclusives, prix liés à l'occupation, inventaire séparé des tarifs, restrictions qui n'existent pas, du XML là où tu attendais du JSON.
6. La casse permanente. Comme pour toute API partenaire : ça ne tombe jamais à zéro.

En résumé, honnêtement : Booking.com est une intégration plus lourde qu'Airbnb et ne partage presque aucune de ses hypothèses — autre modèle d'authentification, autre modèle de données, autre sémantique des dates, autre définition d'une écriture réussie. Les équipes qui viennent de finir Airbnb le sous-estiment systématiquement. Le guide de l'API Airbnb sert de comparaison.

Où se situe Repull

Repull, c'est une seule API REST et une seule clé pour Booking.com, Airbnb, Vrbo, Plum Guide et les logiciels de gestion que les hôtes utilisent déjà. On gère les relations partenaires ; les établissements se connectent eux-mêmes via un flux hébergé à tes couleurs.

• Un seul flux de connexion hébergé. POST /v1/connect/{provider}, avec le rattachement des chambres intégré. Connect.
• Des écritures qui te disent la vérité.Vérification par relecture sur les tarifs, occupation résolue et renvoyée, restrictions non prises en charge refusées plutôt qu'abandonnées, plages de dates inclusives aux deux bouts.
• Une écriture de calendrier pour tous les canaux. PUT /v1/availability/{propertyId} envoie le prix et la disponibilité à tous les canaux auxquels un établissement est connecté.
• Des webhooks avec historique de livraison et rejeu, au lieu de la plomberie de notifications propre à chaque canal. Webhooks.

Commence par le démarrage rapide, ou lis la présentation des canaux. Si tu es une plateforme qui intègre tout ça pour ses propres clients plutôt que pour elle-même, le guide pour les plateformes couvre ce modèle question par question.

Si les établissements que tu intègres sont déjà dans un logiciel de gestion, c'est un deuxième problème, distinct : un PMS te donne sa propre vision d'une réservation, pas l'API du canal. Les guides Guesty, Hostaway, Hospitable, Lodgify et OwnerRez expliquent ce que chacun expose, et la matrice de couverture les liste tous. Une seule clé couvre à la fois une connexion PMS et une connexion directe à un canal.

Questions fréquentes