Documentation · PMS interface

Webhooks

L'API que le PMS expose pour recevoir les réservations de Bridg_ : add, update, cancel, configurations — à enregistrer dans Réglages → API du PMS.

Staginghttps://staging.bridgchannel.appv1.0 · 2026-09-11<?Label BRIDG|DOC|1.0|NEW?>

This technical documentation is available in French only.

Sur une connexion JSON (json), Bridg_ appelle l'API HTTPS du PMS pour lui transmettre les réservations OTA et directes, et pour lire son catalogue. Le PMS expose quatre endpoints sous une URL de base qu'il communique à Bridg_ ; Bridg_ s'y authentifie avec les jetons que le PMS lui a remis.

Ce dialecte est de style Connector API (PascalCase, jetons dans le corps, RPC en POST).

Configuration

Le PMS remet à l'hôtel (ou à Bridg_) l'adresse de son API et deux jetons. Le propriétaire les enregistre dans l'écran Interface PMS → Réglages → API du PMS :

Champ Description
Adresse de base (pmsBaseUrl) URL de base de l'API du PMS, HTTPS, sans /api/… ni slash final (ex. https://api.monpms.com). Bridg_ y ajoute lui-même les chemins ci-dessous.
clientToken jeton identifiant Bridg_ auprès du PMS
accessToken jeton d'accès de l'établissement (secret : stocké chiffré, jamais réaffiché)

Toute modification demande de ressaisir les deux jetons. Le bouton Tester la connexion du même écran appelle configurations/get et affiche les types de chambre et plans tarifaires reçus : c'est la vérification à faire avant d'activer la connexion.

Tant que l'API du PMS n'est pas enregistrée, chaque émission est mise en échec avec le code NO_OUTBOUND_CONFIG (visible dans le journal, rejouable une fois l'API enregistrée).

Endpoints à exposer par le PMS

Méthode Chemin (relatif à pmsBaseUrl) Rôle Requis
POST /api/connector/v1/bookings/add création d'une réservation oui
POST /api/connector/v1/bookings/update modification (état complet) oui
POST /api/connector/v1/bookings/cancel annulation oui
POST /api/connector/v1/configurations/get catalogue : types de chambre et plans tarifaires recommandé — sert au test de connexion et au pré-remplissage des codes

Tous les corps portent l'authentification, à côté des champs propres à chaque appel :

JSON
{ "ClientToken": "…", "AccessToken": "…", "Client": "Bridg Channel Manager" }
Champ Description
ClientToken le clientToken configuré
AccessToken l'accessToken configuré
Client nom de l'appelant : Bridg Channel Manager

Le PMS doit refuser 401 tout appel dont les jetons sont inconnus.

Get configuration

Appelé par le bouton Tester la connexion (Réglages → API du PMS) ; les codes reçus aident à remplir la correspondance des codes.

Request (envoyée par Bridg_)

POST{pmsBaseUrl}/api/connector/v1/configurations/get
Content-Type: application/json
JSON
{ "ClientToken": "ct_…", "AccessToken": "at_…", "Client": "Bridg Channel Manager" }

Expected Response

200 OK

JSON
{
  "UnitTypes": [
    { "Code": "DLX", "Label": { "fr": "Chambre Deluxe", "en": "Deluxe Room" }, "Capacity": 2 },
    { "Code": "SUP", "Label": "Chambre Supérieure", "Capacity": 3 }
  ],
  "RatePlans": [
    { "Code": "BAR1", "Label": { "fr": "Meilleur tarif", "en": "Best Available Rate" } },
    { "Code": "NRF", "Label": "Non remboursable" }
  ]
}
Champ Type Requis Description
UnitTypes[].Code string oui Code stable du type de chambre (celui des messages ARI).
UnitTypes[].Label string ou { lang: string } oui Libellé ; fr est préféré, puis en, puis le premier.
UnitTypes[].Capacity integer non Occupation maximale.
RatePlans[].Code string oui Code stable du plan tarifaire.
RatePlans[].Label string ou map oui Libellé.

Toute réponse non 2xx ou sans UnitTypes[] / RatePlans[] est présentée à l'opérateur comme PMS_UNREACHABLE.

Add booking

Request (envoyée par Bridg_)

POST{pmsBaseUrl}/api/connector/v1/bookings/add
Content-Type: application/json
Idempotency-Key: BRG-2026-001234:r1
JSON
{
  "ClientToken": "ct_…",
  "AccessToken": "at_…",
  "Client": "Bridg Channel Manager",
  "Booking": {
    "ExternalRef": "4412345678",
    "CmRef": "BRG-2026-001234",
    "Channel": "BOOKING_COM",
    "Revision": 1,
    "Currency": "DZD",
    "TotalAmount": { "Gross": 36000, "Net": 36000 },
    "PaymentType": "ON_SITE",
    "Booker": { "LastName": "Benali", "FirstName": "Samir", "Email": "samir.benali@example.com", "Phone": "+213550000000" },
    "Reservations": [
      {
        "LineCode": "01",
        "State": "CONFIRMED",
        "UnitTypeCode": "DLX",
        "RatePlanCode": "BAR1",
        "From": "2026-10-10",
        "To": "2026-10-13",
        "Occupancy": [ { "Bucket": "ADULT", "Count": 2 } ],
        "Nights": [
          { "Date": "2026-10-10", "Gross": 12000, "Net": 12000 },
          { "Date": "2026-10-11", "Gross": 12000, "Net": 12000 },
          { "Date": "2026-10-12", "Gross": 12000, "Net": 12000 }
        ]
      }
    ]
  }
}

Champs facultatifs de Booking, présents seulement quand la réservation les porte :

Champ Type Description
Booker.Country, Customer.Country string Code pays ISO alpha-2 du client.
BookedAt string (ISO 8601) Date et heure de prise de la réservation.
Remarks string Demandes du client en texte libre (demandes spéciales, régime, heure d'arrivée prévue), à reprendre en note pour la réception.
CurrencyConversion object { FromCurrency, FromAmount, ToCurrency, Rate, RateAt }. Présent quand la réservation a été prise dans une autre devise que celle de l'établissement (une réservation Booking.com en euros pour un hôtel en francs CFA, par exemple) : Currency, TotalAmount et les nuits sont alors convertis dans la devise de l'établissement au taux figé sur la réservation (1 FromCurrency = Rate ToCurrency), arrondis à l'unité de cette devise (aucune décimale pour XOF / XAF) ; FromAmount est le montant d'origine. Le PMS reçoit donc toujours la devise de l'établissement.

Expected Response

200 OK (ou tout 2xx)

JSON
{
  "BookingId": "pms-booking-889",
  "Reference": "1543299",
  "Reservations": [
    { "LineCode": "01", "ReservationId": "pms-res-1201", "Reference": "1543299-1", "State": "CONFIRMED" }
  ]
}
Champ Type Requis Description
BookingId string oui Identifiant du groupe côté PMS.
Reference string oui Numéro de confirmation côté PMS (affiché dans le journal).
Reservations[] array oui Une entrée par ligne, appariée par LineCode.
Reservations[].ReservationId, .Reference, .State string oui Identifiants et état de la ligne côté PMS.

Error Response (renvoyée par le PMS)

HTTP Sens Réaction de Bridg_
403 règle métier violée (code non mappé côté PMS, écart de total…) dead-letter (FAILED), visible et rejouable à la main
409 conflit : révision périmée, réservation déjà annulée dead-letter
autre 4xx rejet déterministe dead-letter
429, 5xx, timeout, erreur réseau, corps de réponse invalide transitoire rejeu avec backoff

Corps d'erreur attendu (facultatif mais journalisé) :

JSON
{ "Message": "Unit type DLX is not mapped", "Details": { "code": "UNMAPPED_UNIT_TYPE" } }

Update booking

Même corps que add, avec Revision incrémentée et l'en-tête X-Bridg-Update-Mode.

POST{pmsBaseUrl}/api/connector/v1/bookings/update
Content-Type: application/json
Idempotency-Key: BRG-2026-001234:r2
X-Bridg-Update-Mode: REPLACE
Mode Sens
REPLACE Booking.Reservations porte toutes les lignes ; toute ligne absente est annulée. C'est le seul mode émis aujourd'hui.
DIFF réservé : seules les lignes modifiées seraient envoyées.

Le PMS doit ignorer (409) une Revision inférieure ou égale à la dernière appliquée, et apparier les lignes sur LineCode.

Réponse attendue : identique à add.

Cancel booking

POST{pmsBaseUrl}/api/connector/v1/bookings/cancel
Content-Type: application/json
Idempotency-Key: BRG-2026-001234:r3
JSON
{
  "ClientToken": "ct_…",
  "AccessToken": "at_…",
  "Client": "Bridg Channel Manager",
  "CmRef": "BRG-2026-001234",
  "Revision": 3,
  "CancelAll": true
}
Champ Description
CmRef numéro de réservation Bridg_
Revision révision de l'annulation
CancelAll: true annule tout le groupe. Variante Cancel: ["01"] (liste de LineCode) réservée.

Réponse attendue : identique à add, les lignes en State: "CANCELLED".

Livraison et rejeu

Paramètre Valeur
Déclenchement à chaque création, modification, annulation dans Bridg_ (OTA et direct), connexion ACTIVE
Connexion PENDING ou PAUSED rien n'est émis ; la réservation est retenue au journal (CONNECTION_PENDING / CONNECTION_PAUSED), une ligne par réservation, et part quand le propriétaire la rejoue — une par une ou toutes d'un coup — une fois la connexion ACTIVE
Réservation que le PMS n'a jamais reçue une modification part en add ; une annulation ne part pas (rien à annuler)
Échec avant l'envoi la réservation n'est jamais perdue : une ligne FAILED (EMIT_FAILED) dit la cause et se rejoue depuis la réservation
Ordre FIFO par connexion, garanti par réservation
Timeout d'appel 30 s
Rejeu (transitoire) backoff exponentiel : 30 s, 1 min, 2 min, 4 min… plafonné à 30 min ; 8 tentatives (environ une heure) puis dead-letter, rejouable à la main
Refus déterministe (4xx) dead-letter immédiat, rejouable à la main depuis l'écran Interface PMS
Idempotence en-tête Idempotency-Key = <CmRef>:r<Revision> — le PMS doit renvoyer la même réponse à une clé déjà vue

Sécurité

  • HTTPS obligatoire côté PMS ; certificat valide (pas d'auto-signé).
  • Les jetons voyagent dans le corps ; le PMS doit les comparer en temps constant.
  • Le PMS peut restreindre l'accès aux adresses IP sortantes de Bridg_ (communiquées sur demande).
  • Aucune donnée de carte n'est transmise ; PaymentCardToken, s'il est présent, est un jeton PSP.