Cycle de vie
La vie d'une transaction et de ses enrichissements, du premier appel à l'expiration du contenu : rejeux, rafraîchissements, résultat courant, purge à 90 jours et ce qui survit.
Cette page suit une transaction dans le temps. Elle suppose que les appels portent un external_transaction_id et une Idempotency-Key, comme recommandé.
Chronologie
| Moment | Événement | Ce que voit le client |
|---|---|---|
| J0, premier appel | Création : Noryo calcule, règle, mémorise la réponse sous l'Idempotency-Key, enregistre la transaction et son entrée économique | 200, enr_A, statut du résultat, usage |
| J0, reprise avec la même clé | Rejeu idempotent | 200, même corps, Noryo-Idempotency-Replayed: true |
| J0 à J0 + 24 h | La clé reste liée à cette requête | Une autre requête avec la même clé : 409 idempotency_key_reuse |
| Au-delà de 24 h | La mémoire d'idempotence expire | La clé est libre ; la transaction, elle, reste connue |
| N'importe quand, même transaction renvoyée | Déduplication économique | 200, résultat courant, deduplicated: true, non facturé |
| N'importe quand, rafraîchissement | Nouveau calcul de la même transaction | 200, nouvel enr_B, en-tête Location |
| J0 + 90 jours | Le contenu de chaque résultat est purgé à l'issue de sa rétention | GET : 410 result_content_expired |
| Après la purge, même transaction renvoyée | La transaction est connue, son contenu non | 410 result_content_expired |
| Après la purge, rafraîchissement | Nouveau calcul, nouveau contenu | 200, nouvel enrichment_id, facturé s'il aboutit |
La rétention de 90 jours s'applique au contenu de chaque résultat ; un résultat produit par un rafraîchissement a sa propre durée de conservation. Un résultat not_found n'a pas de contenu : il n'est jamais purgé et ne rend jamais 410.
Le résultat courant
Une transaction a toujours un résultat courant, celui qu'un nouvel envoi rend en déduplication :
- au départ, c'est le résultat de la création, quel que soit son statut (
resolved,partialounot_found) ; - un rafraîchissement qui aboutit (
refresh_recalculated) le remplace ; - un rafraîchissement
partialounot_foundest consigné avec son propreenrichment_id, mais ne le remplace pas ; - une panne du moteur (
503 engine_error) ne crée aucun résultat et ne remplace rien : l'enrichment_idque porte son corps ne désigne que la tentative échouée.
Chaque enrichment_id est figé
enr_A ──> résultat de la création (toujours lisible tel quel jusqu'à sa purge)
enr_B ──> résultat du rafraîchissement (devient le résultat courant s'il est refresh_recalculated)Une lecture GET rend le résultat de l'identifiant demandé, jamais un autre. Pour suivre le dernier résultat d'une transaction, enregistrez l'identifiant rendu par chaque rafraîchissement.
Ce qui survit à la purge
| Élément | Après 90 jours |
|---|---|
Contenu du résultat (merchant, statut lisible) | Purgé |
enrichment_id | Conservé : il rend 410, pas 404 |
| Identité économique de la transaction | Conservée : la déduplication et le rafraîchissement restent possibles |
| Ligne de registre, unités, prix, horodatages comptables | Conservés : vous pouvez toujours prouver ce que vous avez acheté et quand |
| Libellé brut | Jamais conservé, à aucun moment |
Sans external_transaction_id
Un enrichissement créé avec une seule Idempotency-Key a une vie plus courte : il est rejouable pendant 24 heures, lisible pendant 90 jours, mais il n'est rattaché à aucune transaction. Il ne se déduplique pas et ne se rafraîchit pas (409 refresh_not_available).
Voir aussi Rafraîchir et Rétention et 410.
Publié le 2026-10-08 21:04 UTC (version 1).