Regrouper les mises à jour
Envoyez un message avec beaucoup d'items plutôt que beaucoup de messages avec un item. Un message ARI peut porter des centaines d'items (plafond : 5 Mo). Un rythme d'un message par établissement et par nature toutes les 30 à 60 secondes est un bon compromis entre fraîcheur et volume.
Séparer les natures
Disponibilité, prix et restrictions sont trois natures distinctes. Un item ne porte qu'une nature ; préférez aussi des messages homogènes : ils sont plus faciles à rejouer et à diagnostiquer.
Delta, pas full sync sur minuterie
Après la synchronisation initiale, n'envoyez que ce qui change. Un full sync répété sur minuterie sature les files sans apporter d'information. Un full sync planifié (nocturne, hebdomadaire) reste un bon filet de sécurité.
Acquitter seulement ce qui est enregistré
Pour les réservations reçues de Bridg_ (feed ou webhook) : acquittez uniquement quand la réservation est écrite dans le PMS. Un acquittement positif signifie « elle est dans le PMS ». Un échec transitoire de votre côté ne doit pas produire d'acquittement : Bridg_ resservira le message.
Distinguer déterministe et transitoire
- Refus déterministe (type de chambre inconnu, réservation introuvable, message illisible) :
signalez-le explicitement (RESULT
FAIL,success: false,4xx). Bridg_ le met en dead-letter, visible par l'hôtelier ; rien ne sert de réémettre. - Échec transitoire (base indisponible, réseau) : côté Bridg_ c'est un
500— réémettez après un délai ; côté PMS, ne renvoyez pas de verdict, le message sera resservi.
Identifiants de message et idempotence
Donnez à chaque message un identifiant unique et stable (messageId JSON, transactionId
XML). Rejouer un message déjà traité renvoie l'accusé mémorisé, sans effet. Pour les réservations,
la clé est référence + révision : deux révisions sont deux messages, un rejeu de la même révision
est un doublon ignoré.
Respecter l'ordre
Bridg_ traite les messages dans l'ordre de réception et sert les réservations sortantes en FIFO (ordre garanti par réservation). Envoyez vos propres messages dans l'ordre chronologique ; ne parallélisez pas les envois pour une même connexion.
Horizon et plages
Envoyez l'ARI sur 365 jours glissants. Une plage est [from, to) en JSON (to exclusif) ou une
durée en nuits en XML ; vérifiez la borne de fin sur une plage courte pendant la recette.
Sécurité
- HTTPS uniquement ; le secret n'est jamais envoyé ailleurs que dans l'en-tête d'authentification,
la signature ou le paramètre
keyde l'URL. - Stockez le secret chiffré, ne le journalisez pas, faites-le tourner en cas de doute (écran Interface PMS → Régénérer).
- Ne transmettez jamais de numéro de carte :
paymentCardTokenest un jeton PSP.
Observabilité
Journalisez chaque message envoyé avec son identifiant et la réponse reçue. Côté Bridg_, l'écran Interface PMS montre les messages entrants (avec le corps exact reçu), les émissions sortantes et les erreurs par message. En cas de désaccord, comparez l'identifiant de message des deux côtés.