Observabilité
Ce que vous pouvez observer de votre intégration (en-têtes, identifiants, page Usage de Platform), ce que Noryo journalise de chaque tentative, et ce qu'il ne journalise jamais.
L'observabilité d'une intégration repose sur deux sources : ce que chaque réponse vous dit, et la page Usage de Platform. Noryo garde de son côté un journal par tentative, que le support consulte à partir du Noryo-Request-Id.
Ce que chaque réponse vous dit
| Signal | Où | À quoi il sert |
|---|---|---|
Noryo-Request-Id | En-tête de chaque réponse | Identifier la tentative, la citer au support |
Statut HTTP et code | Statut, corps d'erreur | Classer les erreurs : à corriger, à reprendre |
enrichment.status, enrichment.reason | Corps 200 | Mesurer la couverture : part de resolved, partial, not_found |
usage.billable, usage.units | Corps 200 des routes POST | Suivre la consommation |
Noryo-Idempotency-Replayed | En-tête des 200 POST | Compter les rejeux, et ne pas compter leur usage deux fois |
usage.deduplicated | Corps 200 des routes POST | Compter les transactions renvoyées |
Noryo-RateLimit-Remaining | En-tête de chaque 200 et des 429 | Anticiper la limite de débit |
enrichment.environment | Corps 200 | Vérifier qu'une clé de Production sert bien la Production |
Ce qu'il est utile de journaliser
Une ligne par tentative, avec : le Noryo-Request-Id, votre Idempotency-Key, la route, le statut HTTP, le code d'erreur s'il y en a un, enrichment.status, Noryo-Idempotency-Replayed, et votre propre mesure de latence. Avec ces champs, vous pouvez calculer votre taux d'erreur, votre taux de reprise, votre couverture et votre consommation sans dépendre d'une autre source.
Ne journalisez ni l'en-tête Authorization, ni le secret de la clé.
La page Usage de Platform
La section Merchant API de la page Usage couvre les trente derniers jours du workspace :
| Vue | Contenu |
|---|---|
| Par jour | Appels, unités, et répartition resolved, partial, not_found, engine_error, 429, rafraîchissements |
| Appels récents | request_id, date, enrichment_id, résultat, type d'appel, unités |
Elle ne compte que les appels qui ont produit un résultat : les tentatives refusées avant le calcul (401, 400 de validation, 429 de votre seau) et les rejeux n'y figurent pas. Elle n'affiche ni latences ni codes HTTP : ces mesures n'existent que dans le journal d'exploitation de Noryo. Pour un suivi exhaustif, vos propres journaux restent la référence.
Ce que Noryo journalise de chaque tentative
Noryo écrit une ligne par tentative HTTP, y compris les tentatives refusées : un 401 ou un 415 laisse aussi sa ligne. Cette ligne porte l'identifiant de la tentative, la route (sous forme de gabarit, jamais le chemin tapé), la méthode, le statut, le code public, l'environnement, le statut du résultat, l'indication de rejeu ou de limite de débit, et le temps passé par étape : authentification, limite de débit, moteur, règlement.
Pour relier les lignes sans désigner personne, le workspace et la clé y figurent sous forme de pseudonymes, et l'Idempotency-Key et l'external_transaction_id sous forme d'empreintes HMAC tronquées, d'où la valeur ne peut pas être retrouvée.
Ce que Noryo ne journalise jamais
- l'en-tête
Authorization, le secret d'une clé, son vérificateur ; - le libellé brut ;
- la valeur brute d'une
Idempotency-Keyou d'unexternal_transaction_id; - le corps de la requête, et l'identité marchande rendue.
C'est pourquoi le support vous demandera un Noryo-Request-Id, et jamais votre libellé ni votre clé.
Publié le 2026-10-09 10:18 UTC (version 2).