Usage et clés d'API

Ce que la page Usage montre

Sur Platform, la page Usage comporte une section Transaction Intelligence. Elle lit un registre tenu par le runtime de l'API : chaque requête authentifiée y est comptée avec le statut HTTP réellement rendu. Elle compte des requêtes, jamais des jetons ni un montant.

Sans sandbox Transaction Intelligence activé pour votre workspace, il n'y a rien à compter : l'activation se fait sur la page Clés d'API.

Le résumé

Cinq nombres, pour la fenêtre choisie :

Sous le résumé, la même fenêtre est ventilée par famille : enrichissements (POST /transactions/v1/enrichments), lectures (GET /transactions/v1/enrichments/{enrichment_id}) et fenêtres de couverture (POST /transactions/v1/coverage-windows).

Par jour (UTC)

Un tableau donne, pour chaque jour de la fenêtre : total, succès, 4xx, 429, 5xx, puis la répartition POST / GET / couvertures. Les jours sont des jours UTC, découpés par le serveur, jamais selon le fuseau de votre navigateur. Un jour sans requête est une ligne à zéro, pas une ligne absente.

Par clé

Un second tableau liste chaque clé Transaction Intelligence du workspace, révoquées comprises : identifiant, nom, état (active ou révoquée), puis total, succès, 4xx, 429 et 5xx sur la fenêtre. Une clé révoquée garde son historique. L'identifiant est celui de la page Clés d'API : le préfixe, l'identifiant public de dix caractères et les quatre derniers caractères. Le secret n'apparaît jamais.

Cliquer sur une clé filtre toute la section sur cette clé ; un identifiant qui n'appartient à aucune clé du workspace est signalé, ce n'est pas une panne.

Trois fenêtres

La section se lit sur trois fenêtres : 24 heures, 7 jours ou 30 jours. Les jours sont des jours UTC. Le registre est conservé 35 jours ; au-delà, la page ne peut plus rien en dire.

Zéro, non observé, indisponible

Trois états qui se ressemblent et que la page distingue :

• Zéro : une lecture a réussi et n'a trouvé aucune requête. C'est une mesure.
• Non observé : le jour est antérieur à la mise en service du registre, ou au-delà de sa rétention. La ligne le dit en toutes lettres, sans nombre. Quand la fenêtre commence avant le début effectif d'observation, le résumé le signale aussi.
• Indisponible : la lecture du registre a échoué. La page n'affiche alors aucun zéro ; elle dit « usage indisponible ». Rechargez ; si cela persiste, contactez le support.

Ce qui est compté, ce qui ne l'est pas

Le registre ne connaît qu'une requête attribuable : une credential valide a été présentée et le limiteur de débit a rendu son verdict. À partir de là, tout compte, quel que soit le résultat : un 422 de schéma, un 404, un 409, un 400 pour JSON illisible ou Idempotency-Key invalide, un 200 de rejeu idempotent, un 429 (compté dans « limitées »).

N'est jamais compté ce qui est refusé avant la lecture de la credential, ou par elle :

• GET /openapi.json, public et sans clé ;
• un 401 : credential absente, mal formée, d'une autre famille, inconnue ou révoquée ;
• un 403 de workspace inactif ;
• les 400 d'hôte non déclaré, 415 et 413, refusés avant toute lecture de credential.

C'est la règle du limiteur de débit : une clé valide consomme un jeton même si la requête finit en 422, et une clé inconnue n'a pas de seau. Voir Limites de débit.

Ce que la page n'est pas

Ce n'est pas un grand livre de facturation. Transaction Intelligence est en sandbox : rien n'est facturé et rien ne se décompte. Les nombres sont des dénombrements de requêtes ; ils ne se convertissent en rien.

Les limites de débit opérationnelles viennent du contrat :

Ce n'est pas non plus un journal des transactions : ni libellé, ni identifiant de transaction, ni corps de requête n'y figurent. Pour désigner une requête précise auprès du support, citez le noryo-request-id de sa réponse.

Les clés sur la page Clés d'API

La page Clés d'API porte, dans sa section Transaction Intelligence, tout ce qui touche aux clés. Une clé Merchant (nry_mer_*) n'ouvre pas Transaction Intelligence, et réciproquement.

Activer le sandbox

L'activation est un choix du workspace, journalisé, réservé à un owner ou un admin. Elle ne crée rien d'autre qu'un droit d'émettre des clés nry_txn_sbx_.

Elle demande d'abord un profil développeur complet pour le workspace : identité, téléphone professionnel, organisation, et ce que vous construisez. Tant qu'un élément manque, l'activation est refusée et aucune clé n'est émise. Voir Accès production.

Créer une clé

Un membre autorisé du workspace nomme la clé, indique son intention et la crée. Le secret complet, nry_txn_sbx_<key_id>.<secret>, est affiché une seule fois. Copiez-le immédiatement : Noryo n'en conserve qu'un vérificateur et ne peut pas vous le redonner. Rangez-le dans une variable d'environnement côté serveur (NORYO_API_KEY dans nos exemples), jamais dans un bundle navigateur, un dépôt public ou un binaire mobile.

Le nombre de clés actives est plafonné par workspace ; le plafond et le compte courant sont affichés sur la page, lus du serveur. Les clés révoquées ne comptent pas. Plafond atteint : révoquez-en une pour en créer une nouvelle.

Aucune clé live ne s'émet : la production n'est pas ouverte. Elle se demande et se revoit, et une approbation ne suffit pas : d'autres conditions la suivent, dont une facturation qui n'existe pas encore. Voir Limites du sandbox et Accès production.

Révoquer une clé

La révocation est immédiate : dès la requête suivante, la clé rend 401 et plus rien n'est compté pour elle. Son historique reste lisible sur la page Usage. Pour remplacer une clé, révoquez-la et créez-en une nouvelle.

Pour aller plus loin

• Authentification : la forme de la credential et l'en-tête Authorization.
• Limites de débit : seau à jetons, 429, Retry-After.
• Erreurs, dont invalid_api_key et rate_limited.
• Quickstart : de l'identité Noryo au premier enrichissement, puis à la page Usage.