BELIVE 360Connect

Prompt IA prêt à l'emploi

Vous développez avec Claude, ChatGPT, Cursor ou Copilot ? Copiez le prompt ci-dessous, remplacez les deux champs entre crochets de la section « Mon contexte », ajoutez la description ou le code de votre module de réservation, et laissez l'assistant produire le connecteur, le récepteur de webhooks et les tests.

PROMPT-INTEGRATION · v1.0
») dans Claude, ChatGPT, Cursor, Copilot ou l'assistant de votre choix, puis ajoutez à la fin la description de votre système ou le code concerné. L'assistant produira la connexion complète dans votre technologie, avec les tests.

Avant de coller, remplacez les deux champs entre crochets de la section « Mon contexte ».

---

DÉBUT DU PROMPT

Tu es un ingénieur senior chargé de connecter mon système de réservation de tables à **Belive Connect**, l'API partenaires de la plateforme Belive 360 (Maroc). Tu dois produire un connecteur complet, prêt à être mis en production, dans la technologie de mon application, en suivant exactement le contrat ci-dessous. Si une information te manque, pose-moi la question avant de coder.

## Mon contexte

- Technologie de mon application : [ex. Laravel 11 / PHP 8.3, base MySQL]
- Mes tables ont des identifiants internes : [ex. entiers 1..24, le nom affiché est "T9"]
- Je joins, à la fin de ce message, la description ou le code de mon module de réservation.

## Objectif

Quand une réservation est validée chez moi, elle doit bloquer la table sur Belive 360. Quand elle est annulée chez moi, la table doit être libérée sur Belive 360. Quand une réservation est prise ou annulée sur Belive 360, mon planning doit se mettre à jour. Chaque client venant de chez moi doit pouvoir entrer avec Belive Terminal (le contrôle d'accès de Belive 360) grâce au code et au lien que Belive me renvoie.

## Contrat de l'API Belive Connect

Base URL : test `https://preprod.belive360.com/functions/v1/partner-api`, production `https://app.belive360.com/functions/v1/partner-api`.
Authentification : en-tête `Authorization: Bearer <clé>`. Clés `blv_test_…` en test, `blv_live_…` en production. Une clé = un établissement. JSON partout.
Dates `YYYY-MM-DD`, créneaux `HH:MM`, fuseau Africa/Casablanca. Horodatages ISO 8601 UTC.
Limite : 60 requêtes / minute / clé → `429` + `Retry-After: 60`.
Erreurs : `{ "error": "<FR>", "error_en": "<EN>", "code": "<CODE>" }`. Toujours tester `code`.

### GET /v1/venue
Réponse : `{ venue:{id,name,slug,status}, reservationMode:"prepaid"|"free", autoConfirm, requestExpiryHours, tables:[{id,name,number,capacityMin,capacityMax,minimumSpend,type,bookable}], slots:[{id,name,start,end,daysOfWeek}], policies|null, currency:"MAD" }`.
`number` est le nom affiché dans le lieu (ex. "T9"). `id` est l'UUID à utiliser dans les autres appels.

### GET /v1/availability?date=YYYY-MM-DD&slot=HH:MM
Réponse : `{ date, slot, tables:[{id,name,available:boolean,blockedBy:"belive"|"partner"|"manual"|null}] }`. `slot` optionnel. Indicatif : la vérité est fixée à la création.

### POST /v1/reservations
Corps : `{ tableId (uuid, requis), date (requis), slot (optionnel ; sans créneau la table est bloquée toute la date), guests (entier, requis, entre capacityMin et capacityMax), customer:{ name (requis), email, phone } (email OU phone requis), notes (≤500), externalRef (≤120, mon identifiant), idempotencyKey (≤120, requis), notifyCustomer (défaut true) }`.
Réponse `201` : `{ beliveReservationId, accessCode:"BLV-XXXX", status:"confirmed", guestAccessUrl, claimUrl, accessLinkExpiresAt, notifications:{email:"sent"|"failed"|"skipped", sms:"skipped"} }`.
Rejeu de la même `idempotencyKey` : `200`, même corps, en-tête `Idempotent-Replayed: true`.
Erreurs : `409 TABLE_TAKEN` (table déjà prise : ne pas réessayer, refuser ou changer de table), `409 VENUE_INACTIVE`, `404 TABLE_NOT_FOUND`, `400 GUESTS_OUT_OF_RANGE`, `400 CUSTOMER_CONTACT_REQUIRED`, `400 IDEMPOTENCY_KEY_REQUIRED`, `400 INVALID_DATE|INVALID_SLOT|INVALID_TABLE|INVALID_GUESTS|INVALID_EMAIL|INVALID_JSON`.
Les réservations créées par ce point sont `confirmed`, sans paiement en ligne et sans commission.

### DELETE /v1/reservations/{beliveReservationId}
Réponse `200` : `{ beliveReservationId, status:"cancelled", cancelledAt }` ; idempotent (`alreadyCancelled:true`). `404 NOT_FOUND` si la réservation n'a pas été créée avec ma clé (les réservations Belive ne s'annulent pas par l'API).

### GET /v1/reservations?from&to&status&page&limit
Réponse : `{ items:[{id, accessCode, status, date, slot, table:{id,name}, guests, customerFirstName, source:"belive"|"manual"|"partner", checkedInAt, createdAt, externalRef (mes réservations seulement), customerEmail, customerPhone (seulement si contactDetailsIncluded)}], page, limit, total, contactDetailsIncluded }`.
Statuts qui bloquent une table : `confirmed`, `completed`, `requested`, `pending`, `partial`. Statuts qui libèrent : `cancelled`, `declined`.

### Webhooks
`GET /v1/webhooks` ; `POST /v1/webhooks { url, events? }` → `201 { id, url, events, active, createdAt, secret:"whsec_…" }` (secret affiché une fois, 5 endpoints max) ; `DELETE /v1/webhooks/{id}` ; `POST /v1/webhooks/test` → `202`.
Événements : `reservation.created`, `reservation.confirmed`, `reservation.cancelled`, `reservation.declined`, `reservation.checked_in`, `webhook.test`.
Corps livré (POST JSON) : `{ id, type, occurredAt, data:{ reservation:{ beliveReservationId, accessCode, status, date, slot, table:{id,name}, guests, customerFirstName, source, externalRef?, checkedInAt, venue:{id,name}, createdAt, updatedAt } } }`.
En-têtes : `X-Belive-Event`, `X-Belive-Delivery` (identifiant unique de livraison), `X-Belive-Signature: t=<timestamp unix>,v1=<hex>` avec `v1 = HMAC-SHA256(secret, "<t>.<corps brut>")`.
Règles : vérifier la signature sur le corps brut avant tout parsing ; rejeter si `|now − t| > 300 s` ; comparer en temps constant ; répondre `2xx` en moins de 10 s ; Belive réessaie 5 fois (1 min, 5 min, 30 min, 2 h, 12 h) donc dédupliquer sur `X-Belive-Delivery` ; l'ordre n'est pas garanti, se fier à `occurredAt` et `status`.

## Ce que tu dois produire

1. **Configuration** : clé API, secret webhook, base URL, lus depuis des variables d'environnement. Jamais dans le code ni dans les logs.
2. **Client HTTP Belive Connect** avec une méthode par point d'entrée, gestion des erreurs par `code`, nouvel essai automatique uniquement sur `429` (après `Retry-After`) et sur les erreurs réseau, jamais sur `409`.
3. **Table de correspondance** entre mes identifiants de tables et les `tableId` Belive, construite depuis `GET /v1/venue` en faisant correspondre `number` à mes noms de tables, stockée en base, rafraîchissable à la demande. Signaler toute table de mon système sans équivalent Belive.
4. **Synchronisation sortante**, branchée sur le cycle de vie de mes réservations :
   - à la validation chez moi : `POST /v1/reservations` avec `idempotencyKey = "<mon id>-v<version>"`, `externalRef = <mon id>`, le créneau de ma réservation, et le contact du client ; stocker `beliveReservationId` et `accessCode` sur ma réservation ; en cas de `TABLE_TAKEN`, marquer ma réservation en conflit et me l'indiquer clairement ;
   - à l'annulation chez moi : `DELETE /v1/reservations/{beliveReservationId}` ;
   - à la modification de table, date, créneau ou couverts : annuler puis recréer avec une nouvelle version de la clé d'idempotence ;
   - afficher `accessCode` sur ma confirmation client, et `guestAccessUrl` si je choisis `notifyCustomer:false`.
5. **Récepteur de webhooks** : route HTTPS, vérification de signature sur le corps brut, réponse immédiate `200`, traitement asynchrone, déduplication sur `X-Belive-Delivery`, puis mise à jour de mon planning : bloquer la table sur `reservation.created` et `reservation.confirmed` quand `source` n'est pas `partner`, la libérer sur `reservation.cancelled` et `reservation.declined`, marquer « arrivé » sur `reservation.checked_in`. Journaliser chaque événement reçu.
6. **Tâche de rapprochement** quotidienne (optionnelle) : `GET /v1/reservations` sur les 7 prochains jours, comparer à mon planning, signaler les écarts.
7. **Tests automatisés** contre l'environnement de test : création, rejeu idempotent, conflit `409`, annulation, réception et vérification d'un `webhook.test`, rejet d'une signature invalide.
8. **Un README** d'exploitation : variables à renseigner, comment créer la clé et l'endpoint dans le portail Belive (Finance → Intégrations & API), la liste de contrôle avant production.

## Contraintes

- Ne jamais écrire la clé API, le secret ou le contenu complet des webhooks dans les journaux.
- Toujours envoyer un `slot` quand ma réservation en a un.
- Ne jamais réessayer un `409 TABLE_TAKEN`.
- Les montants sont en dirhams marocains (MAD), sans centimes dans `minimumSpend`.
- Code lisible, commenté brièvement en français, avec des types explicites quand le langage le permet.

Commence par me résumer en cinq lignes ce que tu vas construire et par me poser tes questions sur mon système. Ensuite, produis le code fichier par fichier.

Après la génération

  1. Créez une clé de test dans le portail Belive (preprod) et mettez-la dans la configuration.
  2. Lancez les tests contre https://preprod.belive360.com/functions/v1/partner-api.
  3. Déclarez votre endpoint de test et appelez POST /v1/webhooks/test.
  4. Suivez la liste de contrôle du guide d'intégration (§11).
  5. Le jour J, créez la clé de production et l'endpoint de production, puis refaites les trois premiers tests sur une table de test.