Aller au contenu
Sandbox

Lire une réponse

Dans quel ordre lire une réponse Merchant API, pourquoi un 200 ne veut pas dire qu'un marchand a été trouvé, et ce que Noryo fait réellement de chacun de vos champs.

Voir en Markdown

Un 200 ne veut pas dire qu'un marchand a été trouvé. Il veut dire que la requête a été réglée. Ce que le moteur a répondu se lit dans enrichment.status.

L'ordre de lecture

  1. Le statut HTTP. 200 : un résultat réglé. Tout autre statut : un objet Problem Details, à traiter selon son code. Voir Erreurs.
  2. enrichment.status. resolved ou refresh_recalculated : identité complète. partial : identité incomplète ou peu sûre. not_found : personne.
  3. enrichment.reason, pour partial et not_found : pourquoi.
  4. merchant, si le statut le permet : name, category, logo_url, location.
  5. merchant.confidence, comme signal de classement, pas comme probabilité.
  6. usage et l'en-tête Noryo-Idempotency-Replayed, si vous suivez votre consommation.
resolved              identité complète, au-dessus du seuil de la politique
partial               il manque quelque chose, ou la confiance est sous le seuil
not_found             le moteur a répondu, et sa réponse est « personne »
refresh_recalculated  un rafraîchissement a produit un nouveau résultat complet

not_found est une réponse normale et complète, pas une erreur ni un échec. Le cas d'échec est le 503 engine_error, et il n'est facturé à personne.

confidence est un score, pas une probabilité

"confidence": 0.94
JSON

Ne lisez pas cela comme « 94 % de chances d'être juste ». Noryo a mesuré que l'ordre de ce score n'est pas monotone en haut de l'intervalle : un 0,99 est moins fiable qu'un 0,90. Voir Confidence.

location est un objet, ou null

"location": { "city": "PARIS", "postal_code": "75018" }
"location": { "city": "MULHOUSE" }
"location": null
JSON

La clé est toujours présente. Absent et inconnu se ressemblent trop pour qu'on vous demande de les distinguer. Voir Location.

Ce que Noryo fait de ce que vous envoyez

descriptor, amount, currency, occurred_at, country et mcc entrent tous dans l'identité économique : deux appels qui ne diffèrent que par le montant sont deux enrichissements distincts, facturés séparément.

Seul descriptor pilote aujourd'hui la résolution. En particulier, country ne filtre pas la réponse. C'est mesuré, pas accidentel : sur notre jeu de calibration, un filtre strict « le pays déclaré doit égaler le pays du marchand » a retiré 95 résultats résolus pour en corriger 15 réellement faux, et sur les homonymes transfrontaliers, là où le gain aurait dû être le plus fort, il en a retiré 36 pour en corriger 1. C'est consigné dans le jeu de calibration et sera remesuré à mesure que la couverture hors de France grandira.

Le libellé brut n'est pas conservé. La rétention est de 0 jour : aucune colonne du module ne peut le stocker, et il n'apparaît dans aucun journal.

currency et country doivent être en majuscules

eur est refusé par un 400, et fr aussi. C'est délibéré : la forme canonique compare ces champs tels quels, donc EUR et eur seraient deux identités économiques distinctes et deux factures pour ce que vous vouliez être un seul appel. Le validateur refuse l'ambiguïté plutôt que de normaliser dans votre dos. Voir Validation.

Que faire de chaque résultat

RésultatUsage raisonnable
resolved, refresh_recalculatedAfficher l'identité ; la stocker de votre côté
partialAfficher avec prudence, ou faire relire ; voir Données partielles
not_foundAfficher le libellé brut ; voir not_found
503 engine_errorReprendre avec la même Idempotency-Key ; voir Reprises

Dans cette section

Publié le 2026-10-08 21:04 UTC (version 1).

Cette page vous a-t-elle aidé ?