API Reference JSON

Le modèle JSON s'adresse aux PMS cloud : une API REST en JSON, une URL par ressource, une authentification par jeton et signature HMAC, un accusé de traitement synchrone dans la réponse HTTP.

Pages du modèle JSON :

• Availability and Rates — POST …/ari
• Bookings — POST …/reservations : réservations prises dans le PMS
• Webhooks — l'API que le PMS expose pour recevoir les réservations de Bridg_

Topologie

Une connexion JSON porte l'identifiant d'adaptateur json (« JSON Connectivity » dans l'écran Interface PMS). Les deux sens passent par HTTPS :

• PMS → Bridg_ : le PMS pousse sa disponibilité, ses prix, ses restrictions et les réservations prises chez lui (POST).
• Bridg_ → PMS : Bridg_ appelle l'API du PMS pour chaque réservation OTA ou directe créée, modifiée ou annulée (webhook). Le PMS n'a rien à venir chercher.

 PMS ──POST …/ari ────────────────▶ Bridg_      (dispo, prix, restrictions)
 PMS ──POST …/reservations ───────▶ Bridg_      (réservations prises au PMS)
 PMS ◀──POST {pmsBaseUrl}/api/connector/v1/bookings/add|update|cancel── Bridg_

L'adresse de l'API du PMS et ses deux jetons s'enregistrent dans l'écran Interface PMS → Réglages → API du PMS (voir Webhooks). Une connexion peut rester en entrée seule ; ses réservations Bridg_ restent alors en échec dans le journal, rejouables une fois l'API enregistrée.

Votre PMS n'a pas d'adresse publique joignable par Bridg_ ? Contactez Bridg_ avant de commencer.

Endpoints

Base : {base}/api/pms/v1/connections/{connectionId}

POST …/messages et GET …/messages (point d'entrée unique et récupération) sont réservés au modèle XML : une connexion JSON n'y reçoit rien.

Authentification

Chaque requête vers Bridg_ porte deux en-têtes :

La signature porte sur les octets exactement envoyés : sérialisez le JSON une fois, signez cette chaîne, envoyez cette chaîne. Les deux en-têtes sont obligatoires (401 UNAUTHORIZED sinon).

// Node.js
const crypto = require('crypto');
const body = JSON.stringify(message);
const signature = 'sha256=' + crypto.createHmac('sha256', SECRET).update(body).digest('hex');
await fetch(`${BASE}/api/pms/v1/connections/${CONNECTION_ID}/ari`, {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${CLIENT_TOKEN}`,
    'X-Bridg-Signature': signature,
    'Content-Type': 'application/json',
  },
  body,
});

# Python
import hmac, hashlib, json, requests
body = json.dumps(message, separators=(',', ':')).encode('utf-8')
signature = 'sha256=' + hmac.new(SECRET.encode(), body, hashlib.sha256).hexdigest()
requests.post(f'{BASE}/api/pms/v1/connections/{CONNECTION_ID}/ari', data=body, headers={
    'Authorization': f'Bearer {CLIENT_TOKEN}',
    'X-Bridg-Signature': signature,
    'Content-Type': 'application/json',
})

# curl
BODY='{"messageId":"ari-2026-09-11-001","items":[{"unitTypeCode":"DLX","from":"2026-10-10","to":"2026-10-13","availability":12}]}'
SIG="sha256=$(printf '%s' "$BODY" | openssl dgst -sha256 -hmac "$SECRET" | sed 's/^.* //')"
curl -X POST "https://staging.bridgchannel.app/api/pms/v1/connections/$CONNECTION_ID/ari" \
  -H "Authorization: Bearer $CLIENT_TOKEN" \
  -H "X-Bridg-Signature: $SIG" \
  -H "Content-Type: application/json" \
  --data-binary "$BODY"

En-tête optionnel sur POST …/ari : Idempotency-Key. Une clé déjà vue sur la connexion renvoie la réponse mémorisée sans retraiter. Le messageId du corps joue déjà ce rôle ; l'en-tête est utile quand le PMS régénère un messageId à chaque tentative.

Conventions

Réponses et erreurs

Codes et sémantique détaillés : API Reference commune.