Ce que c'est
Un auditeur de clés d'idempotence. Il rejoue vos requêtes journalisées selon les règles que suit une API correcte et inscrit chacune comme première écriture, rejeu sûr ou problème.
Audit d'idempotence pour les API de paiement et de commande
Trouvez les requêtes que votre API a débitées deux fois.
Idempotency Ledger lit vos logs de requêtes, inscrit chaque écriture sous sa clé d'idempotence et montre où une relance a créé un deuxième débit, une deuxième commande ou un deuxième virement. Chaque problème indique le montant en jeu et la correction.
Débits par cléNo. 0417
| Heure | Clé | Montant |
|---|---|---|
| 10:00:00 | ik_7f3a | 49.99 |
| 10:00:03 | ik_7f3a | 49.99 |
| 10:05:00 | ik_c044 | 89.00 |
| 10:05:00 | ik_c044 | 89.00 |
| 10:12:00 | ik_f611 | 9.99 |
Trop perçu+89.00 EUR
Pour qui
Les ingénieurs backend et paiements, les SRE et les responsables support qui doivent savoir si un client a vraiment été débité deux fois, et pourquoi.
Ce que ça résout
Les relances sont normales, mais une relance qui refait le travail crée de vrais problèmes d'argent. Les logs les noient dans des milliers de lignes. Le registre les fait remonter en tête avec les totaux.
Auditez votre log de requêtes
Collez ou ouvrez un export de log. Rien n'est envoyé : l'analyse et les contrôles se font dans cette page.
Une requête par ligne, un tableau JSON ou un CSV avec une ligne d'entête.
Les champs sont reconnus par leur nom : time ou ts, method, path ou url, status, clé d'idempotence, identifiant de l'objet créé comme charge_id ou order_id, amount, currency et customer. Le JSON imbriqué et les entêtes Idempotency-Key fonctionnent aussi.
Votre audit s'affiche ici
Collez un log et appuyez sur Auditer le log, ou chargez l'exemple pour voir tous les types de constat.
Ce que le registre signale
Chaque clé répétée est vérifiée dans l'ordre chronologique et comparée à ce qu'un serveur correct aurait dû faire.
Double effet
Même clé, même requête, deux identifiants créés différents. Le serveur a fait le travail deux fois. C'est le cas le plus coûteux.
Course
Deux copies arrivées à moins de deux secondes d'écart ont toutes deux réussi. Fréquent avec les doubles clics et les relances trop agressives.
Contenu incohérent
Une ancienne clé arrive avec de nouveaux paramètres. Un serveur correct refuse avec 422. L'accepter masque des bugs côté client.
Échec partiel
Un 5xx qui a quand même créé un objet, suivi d'une relance qui en a créé un autre. Visible seulement si les logs contiennent les identifiants.
Sans clé
Les écritures sans clé ne peuvent pas être dédoublonnées. Deux écritures identiques rapprochées sont inscrites comme doublon.
Clé expirée
Une clé qui revient après la fenêtre est traitée comme un nouveau travail. Choisissez la fenêtre de votre serveur.
Mode d'emploi
Exportez un log
Prenez les requêtes vers une route ou un service sur une période, depuis les logs de la passerelle, du répartiteur de charge ou de l'application.
Collez ou ouvrez
Lignes JSON, tableau JSON, CSV avec entêtes ou lignes brutes avec des paires key=value : tout fonctionne.
Réglez la fenêtre des clés
Indiquez combien de temps votre serveur garde les clés. Les API à la Stripe utilisent 24 heures.
Lisez le registre
Les problèmes apparaissent en premier avec le montant en jeu. Ouvrez une clé pour voir chaque ligne et la correction, puis copiez le rapport ou téléchargez le CSV.
Bon à savoir
- Un double effet n'est prouvé que si le log contient l'identifiant de l'objet créé. Sans identifiant, les répétitions sont inscrites comme rejeux.
- Les requêtes sont comparées par méthode, chemin et corps, ou par montant, devise et client quand il n'y a pas de corps.
- Les heures sont affichées en UTC, et une heure sans fuseau est lue comme UTC. Les lignes sans heure gardent l'ordre du fichier.
- Les gros logs fonctionnent, mais limitez vos exports aux routes qui vous intéressent pour une lecture plus rapide.
- Rien ne quitte votre navigateur. Retirez quand même les numéros de carte et les données personnelles avant de partager un rapport.
Questions
Une clé d'idempotence, c'est quoi ?
Une valeur unique que le client envoie avec une écriture. Si la même requête revient avec la même clé, le serveur renvoie le premier résultat au lieu de refaire le travail.
Pourquoi un 409 est marqué comme correct ?
Il signifie qu'une seconde copie est arrivée pendant que la première tournait encore et que le serveur a refusé de les exécuter en parallèle. Le client peut relancer plus tard et obtenir le résultat stocké.
Pourquoi une incohérence de contenu compte si un seul débit a eu lieu ?
Accepter de nouveaux paramètres sous une ancienne clé révèle un bug client qui réutilise ses clés. La prochaine fois, il créera un débit erroné qui ressemble à un rejeu.
J'ai besoin d'identifiants dans mes logs ?
Ils rendent l'audit précis. Journalisez l'identifiant de l'objet créé par chaque écriture, comme charge_id ou order_id.