Événements
Rejouer un événement
POSThttps://tupay.apps.lepetittahitien.dev/api/v1/events/{id}/resend
Rejoue un événement vers tous vos endpoints actifs du mode courant.
Le rejeu CRÉE, il ne modifie pas. Une nouvelle livraison est insérée avec un rang supérieur ; l'ancienne reste intacte comme pièce d'audit, et le backoff d'une livraison encore en cours n'est pas perturbé.
L'enveloppe est reconstruite à partir de l'objet stocké et de la version actuelle de l'endpoint. Un endpoint qui aurait changé de version reçoit la forme qu'il attend aujourd'hui, pas celle du jour de l'émission.
⚠️ Votre gestionnaire recevra l'événement une fois de plus avec le même id : dédupliquez dessus.
L'en-tête Idempotency-Key est facultatif ici, et il est HONORÉ : fourni, deux appels ne créent qu'une seule livraison de plus, et le second ne relivre rien. Sans clé, chaque appel crée une livraison supplémentaire, ce qui reste le comportement voulu de cette opération.
Paramètres de chemin
- motif ^evt_exemple evt_9f8c1a2b3d4e5f60
idchaîne· cheminrequisIdentifiant d'événement, tel qu'il apparaît dans l'enveloppe reçue.
Paramètres d’en-tête
- exemple 9f8c1a2b-3d4e-4f60-8a71-5b2c9d0e6f13
Idempotency-Keychaîne· en-têtefacultatifFacultative sur cette opération. Fournie, elle garantit qu'un rejeu ne crée pas une seconde ressource : le corps mémorisé est renvoyé tel quel. Absente, chaque appel crée une ressource de plus, comme avant.
Mêmes règles que sur les opérations qui l'exigent : cloisonnement par marchand, refus 409
idempotency_key_reusesur corps différent, refus 409idempotency_in_progresspendant l'exécution de la première, et rétention de 24 heures.Exception, dite franchement : sur
POST /api-keysetPOST /webhook-endpointsle secret n'est rendu qu'une fois. Il n'est PAS conservé avec le corps mémorisé, sinon il séjournerait 24 heures en base en clair. Un rejeu rend donc la ressource avec son secret ànull. La clé garantit qu'une seule ressource existe, pas que le secret soit redonné.