API Misterbooking v5 : ce qui change concrètement

L'API Misterbooking v5 a été publiée le 20 mai 2026 avec un cycle de dépréciation de 18 mois pour la v4.x. Nos modules ont été rendus compatibles avec les deux versions dès la sortie de la v5, mais quelques changements méritent l'attention si vous exploitez directement l'API pour vos propres développements.

Endpoints renommés

Trois endpoints ont été renommés avec des schémas de nom plus cohérents. L'endpoint /reservations est désormais /bookings, /rates est désormais /rate-plans, /availability est désormais /inventory. Les anciens noms continuent de fonctionner en v5 avec une redirection 301, mais ils émettent un header X-Deprecated qui devra être pris en compte avant la coupure définitive prévue pour novembre 2027.

Structure JSON aplatie

Les objets imbriqués ont été aplatis pour réduire le nombre de niveaux. Un objet booking en v4 contenait booking.customer.contact.email ; en v5, c'est booking.customer_email. Cette simplification allège les payloads de 15 à 20 % en moyenne mais nécessite une adaptation des consommateurs.

Pagination cursor-based

Fin de la pagination par offset (page=N&per_page=M), remplacée par une pagination cursor-based (after=). C'est un gain de performance significatif sur les collections de plus de 10 000 items mais oblige à ne plus stocker de références par index de page.

Webhooks signés HMAC

Les webhooks émis par Misterbooking sont désormais signés HMAC-SHA256 avec une clé partagée par abonné. Il faut vérifier la signature avant de traiter le payload. Un exemple d'implémentation en Node, Python et PHP est disponible dans notre documentation.

Ce que fait MisterBookingHub

Nos modules ont été portés en v5 en mai et exposent aux clients une couche d'abstraction commune. Vous n'avez rien à faire côté configuration : la bascule est transparente. Nous continuons à supporter la v4 jusqu'à la coupure officielle, ce qui vous laisse le temps d'adapter vos propres consommateurs si vous en avez.