# Clés d'API et webhooks

Créer des clés d'API à portée limitée, déclarer des adresses de réception d'évènements, et suivre les livraisons passées avec leur code de réponse.

Source : https://docs.sealtrust.io/console/reglages-developpeurs/

---

C'est la partie technique des réglages. Elle réunit 2 blocs indépendants : les clés d'API d'un côté, les webhooks et leur journal de livraison de l'autre. Chacun dépend d'un droit d'offre différent, donc l'un peut être ouvert quand l'autre est verrouillé.

![L'onglet Développeurs, avec les clés d'API et le journal des webhooks](/console/reglages-developpeurs.fr.webp)

## Ce que l'écran affiche

- Une carte par clé d'API : nom, état, début de la clé, permissions, quota quotidien, dernière utilisation et date de création.
- La fenêtre de création propose 8 permissions : `mint:batch`, `mint:single`, `products:read`, `products:status`, `transfers:create`, `sellout:write`, `webhooks:read`, `webhooks:write`. Elle arrive préremplie sur `mint:batch`, un quota de 1000 par jour et une validité de 365 jours.
- La fenêtre de création de webhook propose 23 types d'évènements, tenus à l'identique de la liste que le serveur accepte.
- Le journal des livraisons : horodatage, abonnement visé, type, état, code de réponse, numéro de tentative et durée. En dépliant une ligne, vous voyez le contenu envoyé et la réponse reçue.

## Ce que vous pouvez y faire

- Créer une clé en choisissant un nom, une marque, des permissions, un quota quotidien et une durée de validité.
- Copier le secret de la clé. Il n'est montré qu'une seule fois, à la création.
- Révoquer une clé active, après confirmation.
- Créer un abonnement webhook en donnant une adresse et en cochant les évènements voulus.
- Filtrer le journal, puis relancer une livraison en échec.

## Ce qui conditionne l'accès

- Le bloc des clés d'API dépend du droit `api_access`, celui des webhooks du droit `webhooks`, qui est un droit distinct.
- À la création d'une clé, le serveur vérifie dans l'ordre que l'offre est active, que le droit `api_access` est présent, puis que le quota de clés n'est pas atteint.
- La base ne conserve du secret que son empreinte et un préfixe de 12 caractères. Un secret perdu ne se retrouve pas.
- Sans durée précisée, une clé expire au bout de 365 jours.
- Le bouton de création de clé reste désactivé tant que le nom, la marque ou au moins une permission manquent.
- Le bouton de création de webhook reste désactivé tant qu'une marque n'est pas choisie, que l'adresse fait moins de 10 caractères, ou qu'aucun évènement n'est coché.
- Le bouton de révocation n'apparaît que sur les clés actives, celui de relance que sur les livraisons en échec.
- Une livraison compte comme livrée quand son code de réponse est compris entre 200 et 299.
- Le journal va chercher les 100 dernières livraisons par abonnement, alors que le serveur en accepte 200 par appel. La liste des clés s'arrête aussi aux 100 dernières.

## Ce que l'écran refuse

- Sans le droit correspondant, le bloc est grisé et recouvert d'un cadenas portant « Fonctionnalité verrouillée ».
- Une adresse de webhook qui n'utilise pas HTTPS est refusée : « Webhook URL must use HTTPS ».
- Relancer une livraison réussie est refusé : « Cannot retry a successful delivery ».
- Relancer une livraison dont le contenu n'a pas été conservé est refusé : « This delivery has no stored payload and cannot be retried; trigger a fresh event instead. »
- La révocation prévient qu'elle est irréversible et que toutes les requêtes en cours avec cette clé vont échouer immédiatement.