Webhooks

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 :

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

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

{ "ClientToken": "…", "AccessToken": "…", "Client": "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_)

Content-Type: application/json

{ "ClientToken": "ct_…", "AccessToken": "at_…", "Client": "Bridg Channel Manager" }

Expected Response

200 OK

{
  "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" }
  ]
}

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

Request resync

Appelé par le bouton Demander au PMS de tout renvoyer (écran PMS de Bridg_), après une correspondance de codes refaite ou un doute sur l'état de Bridg_. Proposé aujourd'hui pour les connexions Bridg HMS seulement.

Request (envoyée par Bridg_)

Content-Type: application/json

{ "ClientToken": "ct_…", "AccessToken": "at_…", "Client": "Bridg Channel Manager" }

Expected Response

200 OK

{ "Accepted": true, "Reservations": 42 }

La réponse n'attend pas le renvoi. Le PMS renvoie ensuite, par les chemins habituels, tout l'ARI de l'horizon (…/ari) et ses réservations futures et en cours (…/reservations), chacune avec une revision supérieure à la précédente.

Get all bookings

Appelé par le bouton Comparer les réservations avec le PMS (Réglages → API du PMS) : Bridg_ lit ce que le PMS tient sur une période de séjour et le compare à ses propres réservations. Lecture seule.

Content-Type: application/json

{ "ClientToken": "ct_…", "AccessToken": "at_…", "Client": "Bridg Channel Manager",
  "StayFrom": "2026-11-01", "StayTo": "2026-12-31", "Scope": "CM", "Limit": 500 }

Réponse attendue :

{ "Bookings": [ { "Origin": "CM", "CmRef": "BRG-2026-001234", "Revision": 2, "Reference": "1543299",
    "Status": "CONFIRMED",
    "Lines": [ { "LineCode": "01", "State": "CONFIRMED", "From": "2026-11-01", "To": "2026-11-03",
                 "UnitTypeCode": "DLX", "RatePlanCode": "BAR1", "Rooms": [] } ] } ],
  "Cursor": null }

Écarts signalés par Bridg_ : réservation active chez Bridg_ absente du PMS, annulée d'un côté et vivante de l'autre, révision du PMS en retard sans envoi en route, nombre de chambres vivantes différent à révision égale, réservation que le PMS dit tenir de Bridg_ et que Bridg_ ne connaît pas. Le séjour (dates, arrivée, départ) n'est pas comparé : le PMS en est la vérité.

Add booking

Request (envoyée par Bridg_)

Content-Type: application/json
Idempotency-Key: BRG-2026-001234:r1

{
  "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 },
    "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 },
          { "Date": "2026-10-11", "Gross": 12000 },
          { "Date": "2026-10-12", "Gross": 12000 }
        ]
      }
    ]
  }
}

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

Expected Response

200 OK (ou tout 2xx)

{
  "BookingId": "pms-booking-889",
  "Reference": "1543299",
  "Reservations": [
    { "LineCode": "01", "ReservationId": "pms-res-1201", "Reference": "1543299-1", "State": "CONFIRMED" }
  ]
}

Error Response (renvoyée par le PMS)

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

{ "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.

Content-Type: application/json
Idempotency-Key: BRG-2026-001234:r2
X-Bridg-Update-Mode: REPLACE

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

Content-Type: application/json
Idempotency-Key: BRG-2026-001234:r3

{
  "ClientToken": "ct_…",
  "AccessToken": "at_…",
  "Client": "Bridg Channel Manager",
  "CmRef": "BRG-2026-001234",
  "Revision": 3,
  "CancelAll": true
}

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

Livraison et rejeu

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.