Journal des changements

Six niveaux subsistent : public, end_user, repairer, recycler, upstream et authority. Les trois niveaux de métier sont des publics distincts : détenir une accréditation n'en ouvre aucune autre.

La réponse exacte. ?access_tier=value_chain répond maintenant 422, sur GET /v1/passport/{identifier}, sur GET /v1/passport/01/{gtin} et sur les trois points d'entrée d'identité vérifiable. detail est la liste de validation habituelle, chaque entrée portant loc, type et msg, et loc nomme access_tier.

Ce que vous faites. Demandez le niveau de votre métier, repairer ou recycler. Vous recevrez moins de champs qu'avant, et ce sont précisément les champs qui ne relèvent pas de votre métier.

Ce que vous faites. Si votre code compare cette valeur à value_chain, reprenez la comparaison. Et attendez-vous à un contenu plus étroit qu'avant : il est désormais filtré sur vos seules accréditations.

Ce que vous faites. Rien. Un champ qui valait null peut désormais porter une adresse.

Trois surfaces sont concernées : GET /v1/certificate/{identifier}, le PDF rendu par GET /v1/certificate/{identifier}/download, et le bloc certificate de GET /v1/resolve/{identifier}.

Ce que vous faites. Rien dans vos appels. Si vous avez recopié la valeur de issuer_name dans votre propre base, remplacez-la par ce que rend l'API aujourd'hui.

Deux refus de POST /v1/originality/read-sig/verify suivent la même règle et valent maintenant Invalid uid_hex et Invalid signature_hex.

Ce que vous faites. Rien, si vous branchez votre code sur le code HTTP, comme le recommande la page des erreurs. Un client qui compare ces phrases caractère par caractère doit reprendre ses comparaisons, ou mieux, les supprimer.

Chaque réponse acceptée porte X-RateLimit-Limit, X-RateLimit-Remaining et X-RateLimit-Reset. Un dépassement renvoie 429, avec detail valant Rate limit exceeded: 30 requests per 60s et un en-tête Retry-After valant 60.

Ce que vous faites. Espacez vos appels au portail et pilotez votre cadence sur X-RateLimit-Remaining. Un parcours humain, chercher un produit puis déclarer une intervention, reste très en dessous de ce plafond.

Le serveur pose désormais ces deux valeurs lui-même, sur chaque ligne : la méthode d'identification qr et l'identifiant technique du produit.

Ce que vous faites. Rien dans vos envois. Le contrat d'une ligne ne change pas, et une ligne qui porterait la méthode d'identification ou l'identifiant technique est refusée en 400, comme tout champ que le contrat ne nomme pas.

Les produits créés par cette voie sont identifiés par QR. Pour des articles NFC, passez par la console.

L'API acceptait ces deux champs et ne les lisait jamais. La valeur que vous y mettiez n'avait aucun effet.

Une ligne de lot accepte désormais cinq champs et rien d'autre : product_name, brand_id, category_id et metadata_uri, qui sont obligatoires, et external_ref, qui est facultatif.

Ce que vous faites. Retirez ces deux colonnes de vos exports CSV et ces deux clefs de vos objets JSON. Si vous avez besoin de rattacher une ligne à une référence de votre côté, utilisez external_ref : c'est le seul champ libre du contrat. Nous le conservons sur la ligne du lot et nous le rendons dans le résultat que lit GET /v1/partner/mint/batch/status/{job_id}. Aucun champ de produit ne le reprend.

Ce retrait fait passer la validation. Depuis le 21 août 2026, il fait aussi créer les produits, voir l'entrée de cette date.

Rejouer la même valeur avec le même lot rend toujours la réponse du premier appel, sans rien refrapper. L'ordre des contrôles a changé le même jour. Le rejeu consomme désormais un jeton de votre plafond de débit, et l'API relit votre corps de requête avant de vous rendre la réponse mise en cache. Un rejeu au-delà du plafond reçoit donc 429. Un rejeu dont le corps est devenu illisible reçoit 400.

Rejouer la même valeur avec un lot différent répond maintenant 409. L'API ne met pas votre second lot en file, et la réponse vous le dit.

{
  "detail": "Idempotency-Key 'lot-2026-08-20-a' was already used with a different request body"
}

Le même code 409 signale aussi qu'un appel portant cette clef est encore en cours de traitement. Le message est alors A request with this Idempotency-Key is already being processed. Lisez le message avant de décider quoi faire : le premier cas vous demande de changer votre clef, le second vous demande d'attendre la fin du traitement en cours.

L'égalité de deux lots porte sur leur contenu une fois lu. L'ordre des lignes, l'ordre des colonnes, le choix entre CSV et JSON et les cellules vides n'y changent rien.

Ce que vous faites. Fabriquez une valeur d'Idempotency-Key par lot distinct. Si votre code réutilise une valeur fixe, ou une valeur dérivée de l'heure à la minute, changez-la maintenant.

Ce que vous faites. Vérifiez que la clef qui interroge le suivi porte mint:batch. Les droits d'une clef se fixent à sa création et aucun écran ne les modifie ensuite, donc il vous faut une nouvelle clef.

Vérifiez d'abord votre plafond de clefs, qui ne compte que les clefs actives. L'offre Essentiel n'en autorise qu'une seule : révoquez l'ancienne, puis créez la nouvelle, en acceptant la coupure entre les deux. L'offre Prestige en autorise cinq : créez la nouvelle, déployez-la, puis révoquez l'ancienne. Révoquer une clef libère immédiatement une place. Une création au-delà du plafond répond 403 avec le code QUOTA_EXCEEDED.

{
  "detail": {
    "code": "FEATURE_NOT_AVAILABLE",
    "feature": "webhooks"
  }
}

Une extinction seule fait exception : envoyer is_active à false et rien d'autre reste possible sans l'offre. Dès qu'un autre champ accompagne cette extinction, l'API exige l'offre.

La création d'un abonnement, POST /v1/partner/webhooks, répond la même chose et l'exigeait déjà avant ce changement.

Ce que vous faites. Rien si votre offre comprend les notifications. Si elle ne les comprend plus, arrêtez de modifier vos abonnements : éteignez-les avec is_active à false seul, ou supprimez-les.

{
  "detail": "Corps de requete illisible : le JSON envoye est mal forme. Envoyez une liste d'objets produit en application/json, ou un fichier CSV en multipart/form-data."
}

Ce que vous faites. Si votre code rejoue automatiquement les réponses de la famille 5xx, ce cas ne le déclenche plus. Une requête refusée en 400 est à corriger, et la rejouer telle quelle donnera le même refus.

Deux conséquences visibles. Au-delà du plafond, vous recevez 429 avec l'en-tête Retry-After, exprimé en secondes. Quand le service de plafonnement est indisponible, vous recevez 503, et l'appel n'a aucun effet : une suppression refusée ainsi ne supprime rien.

Les réponses qui passent portent X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset et X-RateLimit-Scope.

Ce que vous faites. Lisez X-RateLimit-Remaining et ralentissez avant d'atteindre zéro. Si vous interrogez le suivi d'un lot en boucle, espacez vos appels : c'est le point d'entrée le plus exposé à ce plafond. Traitez le 503 comme une indisponibilité passagère et réessayez après un délai.

L'envoi des notifications suit une autre règle : une marque dont l'offre ne comprend plus les notifications ne reçoit plus de livraison, quels que soient les abonnements encore enregistrés.

Ce que vous faites. Rien. Si votre offre ne comprend plus les notifications, vous gardez la main pour inventorier vos abonnements et pour les supprimer.

Aucune date de fin de service n'est attachée à ces adresses. Si votre intégration les appelle déjà, elle continue de fonctionner.

Ce que vous faites. Rien dans l'immédiat. Utilisez la forme /v1 pour toute nouvelle intégration : c'est la forme documentée partout sur ce site.

Un fichier gzip que le serveur ne parvient pas à décompresser répond maintenant 400, avec le motif dans le message. C'est une erreur de la requête, et votre code peut la traiter comme telle.

Un fichier dont le contenu une fois décompressé dépasse le plafond répond 413, et le message indique ce plafond en Mio.

Ce que vous faites. Rien si vos envois sont valides. Si vous compressez à la volée, vérifiez que le flux est complet avant de l'envoyer, et découpez vos lots pour rester sous le plafond. Un lot porte au plus 500 articles.

Un identifiant qui ne désigne aucun lot de votre marque répond toujours unknown, sans rien révéler de plus.

Ce que vous faites. Rien, ces champs s'ajoutent.

Le corps de la requête accepte un champ facultatif proof_code. Sans lui, le niveau vaut declared. Avec un code valide, il vaut customer_code quand le code a été lu par le client, ou work_order quand il vient de l'ordre de travail de la marque. Un code refusé répond 422 et n'enregistre rien du tout : ni l'intervention, ni la consommation du code.

Les interventions enregistrées avant cette date rendent proof_level vide. Une valeur vide ne vaut pas declared : la question n'avait pas été posée.

Ce que vous faites. Si vous affichez l'historique des interventions, traitez la valeur vide comme un cas à part et n'affichez pas « déclaré » à sa place.

Sans ce paramètre, un abonnement qui vous appartient répond 400 avec le code CONFIRMATION_REQUIRED. Avec une valeur qui ne correspond pas, la réponse est 400 avec le code CONFIRMATION_MISMATCH, et l'API ne modifie rien. Une suppression réussie répond 204.

Un identifiant qui ne désigne aucun abonnement de votre marque répond 404, que vous ayez envoyé confirm ou non : l'API cherche votre abonnement avant de regarder votre confirmation.

Un appel qui n'envoyait que l'identifiant est donc refusé.

Ce que vous faites. Lisez l'adresse avec GET /v1/partner/webhooks/{webhook_id}, puis renvoyez-la dans confirm.

curl -X DELETE \
  "https://api.sealtrust.io/v1/partner/webhooks/1?confirm=https%3A%2F%2Fexemple-sas.example%2Fwebhooks%2Fsealtrust" \
  -H "Authorization: Bearer st_test_0000000000000000000000000000000000000000000000"

Ce que vous faites. Rien, cet en-tête s'ajoute.

X-Webhook-Id est l'empreinte du corps de la livraison. Les réessais d'une même livraison portent la même valeur, ce qui vous permet d'écarter un réessai. Deux événements distincts dont le corps est identique portent eux aussi la même valeur.

Ce que vous faites. Dédoublonnez sur le couple formé du nom de l'événement, porté par X-Webhook-Event depuis le 11 août 2026, et de X-Webhook-Id. N'écartez jamais une livraison sur la valeur de X-Webhook-Timestamp : cet horodatage change à chaque réessai, donc il vous ferait traiter deux fois la même livraison.

Le corps signé est la suite d'octets reçue sur le fil. Décoder le JSON puis le réencoder avant de vérifier casse la signature, parce que le réencodage ne rend pas les mêmes octets.

Ce que vous faites. Vérifiez la signature sur le corps brut de la requête, avant tout décodage.

Une clef qui ne porte pas le droit reçoit 403, et le message nomme le droit manquant.

Ce que vous faites. Vérifiez les droits de la clef qui gère vos abonnements. Si elle a été créée avec le seul droit mint:batch, créez une nouvelle clef portant aussi les droits de notification.

Les adresses sans préfixe répondent en plus deux en-têtes, Deprecation: true et Sunset: 2026-09-01. Les adresses en /v1 ne les portent pas. L'entrée du 16 août 2026 retire ces deux en-têtes et aucune date de fin de service n'a été appliquée.

Ce que vous faites. Rien. Les deux adresses appellent le même code.