Idempotence

Le réseau d’une caisse coupe parfois au mauvais moment. Remizo garantit qu’un appel rejoué ne produit jamais deux fois le même effet (double crédit de points, coupon consommé deux fois).

L’en-tête Idempotency-Key

Accepté sur tout POST qui crée quelque chose (moteur et hub), de 8 à 128 caractères.

• La clé, l’empreinte de la requête et la réponse sont conservées 48 heures, par appelant et par route.
• Même clé + même corps → la réponse d’origine est renvoyée, avec l’en-tête Idempotent-Replay: true.
• Même clé + corps différent → 422 idempotency-key-reused.

Choisissez une clé stable dérivée de l’opération métier : numéro de commande, <storeCode>:<posId>:<ticketNumber>:commit, birthday:<idClient>:<date>.

La clé de ticket

Indépendamment de l’en-tête, chaque ticket a une identité métier :

<storeCode>:<posId>:<businessDate>:<ticketNumber>      ex. S042:03:2026-11-09:000123

Situation	Comportement
evaluate d’une clé en attente, même corps	rejeu de la réponse (Idempotent-Replay: true)
evaluate d’une clé en attente, corps différent	nouvelle évaluation qui remplace la précédente (la caisse a modifié le ticket)
evaluate d’une clé validée	409 ticket-key-committed (ou rejeu si même Idempotency-Key)
commit / cancel répétés	rejeu du résultat

Autres opérations

• Réservations de points : idempotentes sur Idempotency-Key ; confirm est idempotent par nature.
• Événements client : idempotents sur Idempotency-Key.
• Consommation de coupon hors ticket (/v1/coupons/redeem) : idempotente sur Idempotency-Key.
• Webhooks sortants et messages internes : chaque livraison porte un identifiant unique (X-Remizo-Delivery) ; dédupliquez côté récepteur.

Brouillons d’offres (hub)

Les brouillons utilisent l’ETag : GET renvoie ETag, PUT /offers/{id}/draft exige If-Match. Si quelqu’un a modifié le brouillon entre-temps, la réponse est 412 : rechargez et réappliquez vos changements.