$ INGÉNIERIE · 20 AOÛT 2026 · 8 MIN
L'API Misterbooking Cloud v3 en pratique
La version 3 de l'API Misterbooking Cloud est disponible en production depuis mi-juillet 2026. Nous avons migré nos dix connecteurs sur trois semaines, en priorisant les modules de distribution (Booking.com, Expedia, channel manager étendu) avant les modules d'analyse. Ce billet dresse un état des lieux honnête de la migration : ce qui a bien fonctionné, ce qui a demandé des adaptations, et les choix d'ingénierie que nous avons faits.
Ce qui change dans l'API v3
Trois évolutions structurantes : la pagination par cursor plutôt que par offset, la souscription temps réel aux événements de réservation via un canal WebSocket signé, et la refonte du modèle de tarification qui expose désormais explicitement les restrictions de séjour minimum, les fermetures à l'arrivée et les fermetures au départ dans un objet dédié plutôt que dans des champs dérivés.
Pagination par cursor
Ce changement était attendu depuis longtemps. La pagination par offset devenait problématique sur les gros comptes multi-propriétés — les extractions mensuelles de plusieurs dizaines de milliers de réservations généraient des incohérences quand une réservation était modifiée pendant la pagination. Le cursor résout élégamment ce cas. La migration a demandé de repenser notre logique d'extraction batch pour traiter le cursor comme un état persistant, mais rien de plus.
Souscription temps réel WebSocket
C'est la fonctionnalité qui a le plus modifié notre architecture. Avant, nous polings les webhooks entrants toutes les 30 secondes. Nous consommons désormais un flux WebSocket signé HMAC-SHA256 qui pousse les événements en moins de 500 ms. Le gain est net pour le module Widget Réservation Directe, qui affiche désormais les disponibilités mises à jour avant même que l'utilisateur n'ait terminé de saisir ses dates.
Modèle de tarification refondu
Le nouveau modèle est plus verbeux mais plus lisible. Nos connecteurs ont dû recompiler leurs schémas de mapping, ce qui a pris deux jours de développement et une journée de tests de non-régression. En revanche, la gestion des restrictions de séjour minimum par plage de dates est désormais triviale — c'était un point de friction récurrent en v2.
Points de vigilance
Le rate limit reste à 600 requêtes par minute par jeton. Nos connecteurs OTA respectent ce plafond avec une marge de sécurité de 20 %. Nous conseillons aux hôteliers qui exploitent plusieurs modules simultanément de générer un jeton par module plutôt que de mutualiser, afin de préserver les quotas.
Prochaines étapes
Nous préparons pour l'automne l'exploitation des souscriptions WebSocket dans le module Analyse Revenus, ce qui permettra un rafraîchissement des tableaux de bord en temps réel plutôt qu'en batch nocturne. Un changelog détaillé sera publié à chaque étape.