Journal des changements

La réponse que vous recevez maintenant. Ces appels répondent comme sur l'offre Conformité + Identité. GET /timeline/{identifier} et GET /my-products portent identity_included à true pour ces pièces. Créer une pièce, commander un encodage de puces et émettre un nouveau code d'achat répondent toujours 403 OFFER_EXCLUDES_IDENTITY sur l'offre Conformité.

Ce que vous faites. Rien. Si votre intégration masquait la revendication ou le transfert d'après l'offre de la marque, lisez plutôt identity_included de la pièce.

La réponse que vous recevez maintenant. Sans jeton, POST /admin/mcp répond 401 avec un en-tête WWW-Authenticate qui donne l'adresse des métadonnées de la ressource. Claude suit cette adresse, s'enregistre, puis vous envoie sur la page « Connecter un assistant IA » de la console. Un jeton vaut 30 minutes, une connexion 90 jours au plus. Au-delà de 60 appels d'outil par minute et par connexion, la réponse est 429 avec un en-tête Retry-After. Un compte de l'équipe SealTrust ne peut pas être connecté. « Préparer des brouillons » n'est jamais coché d'avance, et changer ou réinitialiser votre mot de passe met fin à vos connexions. Le détail est dans Brancher le serveur MCP.

Ce que vous faites. Rien pour une intégration existante. Pour mettre fin à une connexion, ouvrez Paramètres, puis Développeurs, carte « Assistants IA connectés ».

La réponse que vous recevez maintenant. Un 422 pour un secret trop court ou vide, et pour un secret null dans une modification, avec loc qui nomme secret. Une création sans secret répond 201 avec un champ secret en plus : c'est la seule fois qu'il est lisible. Une création avec votre secret ne le renvoie pas, comme avant.

Ce que vous faites. Si votre secret fait moins de 32 caractères, prenez-en un plus long. Si vous créez sans secret, lisez le champ secret de la réponse et configurez-le sur votre récepteur. Pour garder le secret actuel dans une modification, omettez le champ au lieu d'envoyer null.

La réponse que vous recevez maintenant. Après un changement de secret, les réessais en attente arrivent signés avec le nouveau secret.

Ce que vous faites. Rien, si votre récepteur accepte les deux secrets pendant une bascule, comme cette documentation le conseille.

La réponse que vous recevez maintenant. Le transport est le HTTP diffusable de la spécification MCP, sans session : chaque message est un POST indépendant, et un GET ou un DELETE répond 405. Une requête qui porte un en-tête Origin d'un autre site que Claude ou ChatGPT répond 403. Au-delà de 300 requêtes par minute et par adresse, ou de 120 appels d'outil par minute et par client, la réponse est 429 avec un en-tête Retry-After. Le détail est dans Claude et ChatGPT en 30 secondes.

Ce que vous faites. Rien si vous utilisez le paquet npm : il ne change pas. Pour un assistant en ligne, collez l'adresse au lieu d'installer quoi que ce soit.

• GET /partner/catalog/brands/{brand_code}/batches, un lot avec ?batch_code= ou la liste des lots ;
• GET /partner/catalog/brands/{brand_code}/passports/list, la dernière version de chaque passeport de modèle et de lot, sans son contenu ;
• POST /partner/catalog/brands/{brand_code}/passports/preview, ce que chaque public verra d'un brouillon, sans rien écrire ;
• GET /partner/catalog/brands/{brand_code}/templates et GET /partner/catalog/brands/{brand_code}/templates/{template_key}, les gabarits de passeport.

L'écriture du passeport brouillon accepte un champ de plus, only_if_draft. À true, elle ne complète que le brouillon ouvert : une dernière version scellée ou publiée est refusée en 409, et aucune version du tout en 404.

La réponse que vous recevez maintenant. Les mêmes réponses qu'avant sur les points d'entrée existants. Sans only_if_draft, un envoi sur une version scellée ouvre toujours la version suivante.

Ce que vous faites. Rien. Le détail est sur la page Remplir le catalogue par l'API.

La réponse que vous recevez maintenant. Quand la liste media d'une pièce ne contient aucune image, l'image de couverture du modèle y est ajoutée en premier, avec l'identifiant 0, media_type à image et l'adresse publique de la photo. Une pièce qui a sa propre photo garde exactement sa liste.

Ce que vous faites. Rien. Si vous preniez la première image de media comme vignette, elle apparaît désormais. Ne cherchez pas l'entrée d'identifiant 0 dans la médiathèque de la marque : elle n'a pas d'enregistrement propre.

La réponse que vous recevez maintenant. Quand le compte appelant est le détenteur enregistré de la pièce, la réponse est 409 avec detail « ALREADY_YOURS: you already own this product ». Tout autre compte reçoit exactement la réponse d'avant : la pièce a un propriétaire, jamais lequel.

Ce que vous faites. Lisez le code avant les deux points. Sur ALREADY_YOURS, dites à la personne que le produit est déjà dans son espace, sans l'envoyer vers la marque.

La réponse que vous recevez maintenant. Ces adresses répondaient 404. Elles répondent maintenant comme GET /passport/{identifier}/vc et ses deux voisines, avec en plus level (model ou batch), gtin et, pour un lot, batch_code.

Ce que vous faites. Rien. Pour vérifier le passeport d'un modèle ou d'un lot, appelez la nouvelle adresse.

La réponse que vous recevez maintenant. Ces trois champs, quand le passeport les porte, dans la réponse publique.

Ce que vous faites. Rien.

La réponse que vous recevez maintenant. Au niveau public, le justificatif d'un textile porte composition avec material et percentage de chaque ligne. Il ne les portait pas. Celui d'une batterie ne porte plus les références de pièces, l'état de la batterie ni la durée de vie en cycles.

Ce que vous faites. Rien. Un justificatif déjà émis garde ses divulgations ; il est réémis à la prochaine publication du passeport.

La réponse que vous recevez maintenant. Une valeur mal écrite reçoit un 422 dont detail.code vaut BRAND_REF_NOT_WELL_FORMED. detail.references dit où se trouve la valeur, sans la répéter. Dans un lot envoyé en CSV, la ligne fautive est signalée dans le refus 400 habituel, et son message commence par BRAND_REF_NOT_WELL_FORMED. Le lot entier est refusé et rien n'est créé.

Ce que vous faites. Envoyez le numéro en chiffres seuls, 5 ou "5", ou mieux, le brand_code que donne GET /v1/partner/catalog/brands. Si votre code produit un nombre décimal, convertissez-le en entier avant l'envoi.

La réponse que vous recevez maintenant. Chaque code n'apparaît qu'une fois. Une pièce dont le code a déjà servi reçoit un 409 PURCHASE_CODE_ALREADY_USED, sauf avec "replace_used": true. Une pièce d'une autre marque reçoit le même 404 PIECE_NOT_FOUND qu'une pièce inconnue. La réponse de POST /partner/mint/batch porte un sixième champ, issue_purchase_codes.

Ce que vous faites. Rien si vous n'utilisez pas les codes d'achat. Sinon, cochez claim_codes:issue sur une clef dédiée, jamais coché par défaut, et lisez Émettre les codes d'achat.

La réponse que vous recevez maintenant. Le même champ valid. message vaut « Registered number: the QR signature and the on-chain record match. A QR code can be copied: it does not prove the item in hand is the original. » ou « Unrecognised code: the QR signature or the on-chain record does not match. ».

Ce que vous faites. Rien si vous lisez valid, comme cette page le demande. Si vous affichiez message, n'affichez jamais « authentique » à partir de cette réponse.

La réponse que vous recevez maintenant. Seize champs au lieu de quatorze. Rien d'autre ne change.

Ce que vous faites. Rien d'obligatoire. Si vous affichiez verified_at comme une date de vérification, lisez registered_at et écrivez « enregistré le » : personne n'a vérifié l'objet à cette date.

La réponse que vous recevez maintenant. Un PDF dont le sceau et le pied de page ont changé de texte. Le reste du document est identique.

Ce que vous faites. Rien, sauf si vous comparez le texte du PDF à une valeur attendue.

La réponse que vous recevez maintenant. Les réponses de l'API partenaire, du portail partenaire, de /sdm/verify et des clefs publiques qui rendaient brand_id rendent aussi brand_code. brand_id y est déprécié. Un code qui ne nomme aucune marque reçoit le même 403 qu'une marque que la clef ne sert pas. Une requête qui envoie brand_code et brand_id ensemble est refusée : en 422 pour une vente ou un abonnement, en 400 pour une ligne de lot.

Ce que vous faites. Rien dans l'immédiat : le numéro brand_id est encore accepté partout où il l'était. Remplacez-le par brand_code à votre prochaine évolution. GET /brand/{brand_id}/did.json garde le numéro, parce qu'il fait partie de l'identifiant did:web déjà signé dans les justificatifs émis.

La réponse que vous recevez maintenant. Une adresse dont le code ne nomme aucune marque reçoit le même 404 qu'une marque sans connecteur actif. L'adresse qui porte le numéro de la marque continue de fonctionner.

Ce que vous faites. Rien : une adresse déjà collée dans votre ERP continue de fonctionner. Pour un nouveau connecteur, collez l'adresse que la console affiche.

La réponse que vous recevez maintenant. brand_id y est déprécié. GET /my-products accepte le filtre ?brand_code=.

Ce que vous faites. Rien dans l'immédiat : brand_id est encore rendu. Lisez brand_code à votre prochaine évolution. Si vous lisez l'export par la position des colonnes, décalez de un toutes les colonnes qui suivent brand_id.

La réponse que vous recevez maintenant. Un bloc materials peut apparaître dans data au niveau public. L'origine des matières n'en fait pas partie.

Ce que vous faites. Rien. Si vous affichiez « composition réservée » faute de materials, affichez le bloc quand il est présent.

La réponse que vous recevez maintenant. composition n'apparaît que si une ligne de matière porte au moins un nom, une part ou une origine. Sinon la clef est absente de sections, comme pour un passeport sans matières. Un chiffre laissé vide par la marque n'est jamais rendu comme 0.

Ce que vous faites. Rien. Traitez l'absence de composition comme vous le faites déjà : la marque n'a rien déclaré.

La réponse que vous recevez maintenant. Une adresse qui se termine par .photo.webp : une image WebP de 800 pixels au plus sur le grand côté, de 100 Ko au plus, sans données EXIF. Une photo qui n'a pas encore sa copie garde l'adresse de l'original ; une adresse d'un autre site est rendue telle quelle. Le champ ne change ni de nom ni de type, et null garde le même sens.

Ce que vous faites. Rien. Si votre intégration déduisait le format du fichier de l'extension de l'adresse, lisez l'en-tête Content-Type de la réponse à la place.

La réponse que vous recevez maintenant. Sur une offre payante, un lot envoyé à POST /v1/partner/mint/batch ne reçoit plus le 403 dont detail.code vaut QUOTA_EXCEEDED et detail.resource vaut products. Il est accepté. Un compte d'essai reçoit toujours ce refus, avec "period": "monthly".

Ce que vous faites. Rien. Si votre intégration attendait ce refus pour étaler ses envois d'un mois sur l'autre, vous pouvez retirer cette attente.

La réponse que vous recevez maintenant. Un lot dont les lignes portent le brand_id d'une de vos marques clientes est accepté. La vente et l'abonnement prennent un champ brand_id facultatif, et la liste des abonnements un paramètre brand_id. Une marque que la clef ne sert pas reçoit toujours un 403, dont detail vaut désormais "This API key cannot act for this brand." (le texte "Brand mismatch: ..." disparaît). Un lot qui mélange plusieurs marques reçoit un 422 dont detail.code vaut ONE_BRAND_PER_BATCH.

Ce que vous faites. Rien si vous ne lisiez pas le texte du refus. Si votre intégration le comparait à "Brand mismatch", comparez le code 403 à la place. Avec une clef revendeur, vous pouvez retirer les clefs créées sur vos marques clientes : le détail est sur la page Remplir le catalogue par l'API.

La réponse que vous recevez maintenant. image_url est l'adresse complète de la photographie du modèle, calculée de la même façon aux trois niveaux : sa photo principale, ou à défaut la première image de sa médiathèque. null quand le modèle n'en a pas. Sur le passeport d'une pièce, trois cas changent : une photo enregistrée comme simple chemin de stockage arrive maintenant en adresse complète, un modèle sans photo principale montre la première image de sa médiathèque au lieu de null, et un modèle d'une autre marque que celle du passeport répond null.

Ce que vous faites. Rien : c'est un champ en plus. Affichez-le si votre page montre le produit.

La réponse que vous recevez maintenant. Pour une marque sur l'offre compliance, toute opération sur une pièce répond 403, avec detail.code égal à OFFER_EXCLUDES_IDENTITY et detail.feature qui dit ce qui a été refusé : création de pièces par POST /v1/partner/mint/batch, lecture de puce par POST /v1/partner/nfc/verify, déclaration de vente par POST /v1/partner/sellout, et les mêmes opérations dans la console. Rien n'est écrit, mis en file ou envoyé à la blockchain.

Ce que vous faites. Rien pour une marque qui ne change pas d'offre. Pour une marque sur l'offre compliance, ne rejouez pas un appel refusé avec ce code, et imprimez le QR code de son modèle ou de son lot. Le détail est sur la page Conformité, ou Conformité + Identité.

La réponse que vous recevez maintenant. 200 et une image PNG pour une telle marque. Dans tous les autres cas, la même réponse qu'avant : 410 avec detail.code égal à ITEM_QR_ONLY.

Ce que vous faites. Rien si vos marques sont sur l'offre compliance_identity : elles impriment toujours le code de chaque pièce.

La réponse que vous recevez maintenant. Le code reste 200 et l'image reste un PNG. Pour une marque dont le domaine est vérifié mais pas encore définitif, l'adresse encodée commence par https://sealtrust.io au lieu du domaine de la marque. Cette adresse reste valable pour toujours.

Ce que vous faites. Rien. Si vous imprimez ces codes pour une marque qui veut son domaine sur ses étiquettes, la marque rend d'abord son domaine définitif depuis sa console, par l'export des QR codes d'un lot.

La réponse que vous recevez maintenant. Le code reste 200. Sans authentification, available_tiers vaut ["public"]. La liste ne donne aucun droit : chaque niveau demandé reste vérifié, avec les mêmes refus qu'avant.

Ce que vous faites. Rien. Si vous proposez un choix de niveau à vos utilisateurs, proposez les niveaux de cette liste, et seulement eux. Une réponse faite pour un compte connecté ne doit aller dans aucun cache partagé.

La réponse que vous recevez maintenant. Le code reste 200. Dans passport.data, l'impact environnemental, l'indice de réparabilité, la durée de vie, la durabilité, l'efficacité énergétique, l'empreinte carbone, la matière principale, l'entretien et le mouvement n'apparaissent plus. Le taux de recyclabilité et le contenu recyclé restent. Le bloc evidence ne change pas.

Ce que vous faites. Si votre intégration affiche ces champs, lisez-les sur GET /passport/{identifier} avec un jeton de session de compte dans Authorization: Bearer. Si vous les affichez quand ils manquent, affichez une absence, jamais un zéro : une valeur absente n'est pas une valeur nulle.

La règle vaut pour les six points d'entrée qui prennent access_tier : GET /passport/{identifier}, GET /passport/01/{gtin}, GET /passport/{identifier}/vc, GET /passport/{identifier}/vc/preview, GET /passport/{identifier}/vc/verify et GET /passport/01/{gtin}/10/{lot}.

La réponse que vous recevez maintenant. Un appel sans session au niveau end_user reçoit 401, avec detail égal à End-user-tier access requires authentication. Le niveau public ne change pas.

GET /resolve/{identifier} ne prend pas de paramètre access_tier. Il sert le niveau public, voir l'entrée précédente.

Ce que vous faites. Si votre intégration demande end_user sans session, présentez un jeton de session de compte dans Authorization: Bearer, ou demandez le niveau public. Une clef d'API partenaire n'est pas une session et n'ouvre pas ce niveau.

La réponse exacte. Ces demandes répondent maintenant 404, detail vaut Produit introuvable, exactement comme pour un identifiant inventé. Sur le domaine propre d'une marque, le portail ne trouve que les produits de cette marque. Le 403 Aucune accréditation active ne change pas.

Ce que vous faites. Si votre code traite ce 403 à part, traitez le 404 à la place : le produit n'est pas dans votre périmètre, ou il n'existe pas.

La réponse exacte. Un tel compte reçoit 403 sur GET /v1/passport/{identifier}, GET /v1/passport/01/{gtin}, GET /v1/passport/01/{gtin}/10/{lot} et sur les trois points d'entrée d'identité vérifiable, avec le detail habituel de ce refus. Un réparateur garde le niveau repairer, et un recycleur le niveau recycler.

Ce que vous faites. Rien si vous appelez avec un compte administrateur ou partenaire. Sinon, demandez à la marque le rôle qui correspond à votre usage.

• GET /partner/passports/{identifier}, GET /partner/passports/01/{gtin} et GET /partner/passports/01/{gtin}/10/{lot} rendent le passeport, sa preuve et sa signature en un appel.
• POST /partner/scans et POST /partner/nfc/verify comptent chaque scan pour le visiteur nommé par quatre en-têtes signés, et plus pour votre serveur.
• GET /partner/nfc/receipts/{receipt} lit une lecture de puce que notre page a déjà vérifiée : la puce n'est vérifiée qu'une fois.
• POST /partner/nfc/verify répond 503 NFC_READ_IN_PROGRESS, avec Retry-After, à une relance qui arrive pendant que votre premier appel vérifie encore la même lecture, au lieu de la prendre pour une copie.
• Nos pages /claim et /transfer acceptent serial et return et renvoient le visiteur vers votre page, avec claim_outcome ou transfer_outcome. GET /my-products porte désormais le champ serial.

Une clef revendeur agit aussi pour les marques clientes sur ces six points d'entrée.

Quand une marque l'active dans la console, /p/{serial}, /01/{gtin}/21/{serial}, /01/{gtin} et /01/{gtin}/10/{lot} répondent 302 vers la page du partenaire, et GET /sdm/verify-url porte un champ partner_redirect_url. Sans ce réglage, ces réponses ne changent pas, et le champ vaut null.

Ce que vous faites. Rien pour une intégration existante. Pour afficher les passeports dans votre page, lisez Afficher le passeport dans votre page.

• GET /01/{gtin}/10/{lot}, le lien GS1 du lot, qui répond 302 vers la page du passeport du lot, ou vers celle du modèle quand le lot n'a pas encore de passeport publié ;
• GET /v1/passport/01/{gtin}/10/{lot}, le passeport du lot, avec "level": "batch", product_batch_id et batch_code ;
• GET /v1/passport/01/{gtin}/10/{lot}/proof, ses preuves. Son ancrage sur la chaîne vient du même balayage que les autres passeports, sans aucune frappe.

Un exemplaire sans passeport propre reçoit maintenant celui de son lot quand il en a un, avant celui de son modèle, sur GET /v1/passport/{identifier}, sa preuve, sa vérification, GET /v1/resolve/{identifier} et le portail partenaire.

Ce que vous faites. Rien : aucune réponse existante ne change tant qu'aucun passeport de lot n'est publié. Si votre intégration lit product_id: null comme « passeport du modèle », lisez plutôt le champ level des réponses de niveau partagé, qui vaut model ou batch.

Trois règles protègent les étiquettes de lot déjà imprimées :

• le GTIN d'un modèle dont un lot a un passeport publié ne change plus : PUT /admin/product-models/{id} répond 409, et l'import Excel refuse la ligne ;
• un GTIN n'appartient qu'à une marque, à tous les niveaux : publier un passeport de modèle ou de lot sous un GTIN qu'une autre marque publie déjà, par son modèle ou par l'un de ses lots, répond 409 ;
• publier un brouillon de lot dont le lot a été renommé depuis répond 422.

L'archive de réversibilité écrit pour chaque passeport son level, son product_batch_id et son batch_code.

Une clef revendeur agit aussi pour les marques clientes rattachées au contrat revendeur, sur ces sept points d'entrée seulement.

Chaque lot rendu porte lot_passport_blocker : null quand son code peut porter un passeport de lot, sinon la raison (plus de 20 caractères, ou un caractère que le lien GS1 refuse). Le lot est créé quand même.

Quatre droits qui n'ouvraient aucun point d'entrée ne se proposent plus à la création d'une clef : mint:single, products:read, products:status et transfers:create. Une clef qui en porte déjà un continue de fonctionner exactement comme avant, puisque ce droit n'ouvrait rien.

Ce que vous faites. Rien pour une intégration existante. Pour préremplir votre catalogue, créez une clef portant catalog:write et lisez Remplir le catalogue par l'API.

La réponse que vous recevez maintenant. GET /qr/01/{gtin}, GET /qr/01/{gtin}/download, GET /qr/01/{gtin}/10/{lot} et GET /qr/01/{gtin}/10/{lot}/download répondent 410, avec detail.code égal à ITEM_QR_ONLY. La réponse est la même pour tout GTIN et tout lot, connus ou non. Les liens /01/{gtin} et /01/{gtin}/10/{lot} eux-mêmes ne changent pas : un code déjà imprimé mène toujours à son passeport.

Ce que vous faites. Dessinez le code de chaque exemplaire avec GET /qr/product/{serial}/download. La page de chaque exemplaire affiche le passeport de son lot, sinon celui de son modèle.

• POST /admin/product-models et PUT /partner/catalog/brands/{brand_id}/models créent un modèle au niveau unit, que le corps donne le champ ou non. Les connecteurs et l'import Excel créent aussi au niveau unit. Envoyer "identity_level": "model" répond 422.
• Un modèle encore au niveau model ne reçoit aucun exemplaire : /mint, /mint/batch, /admin/batch/mint, /admin/batch/prepare et /admin/batch/prepare-mapped répondent 409 avec le code MODEL_LEVEL_IDENTITY, avant toute écriture, que la ligne nomme le modèle ou seulement son lot. Le détail ne donne que des identifiants.
• Une ligne qui nomme le modèle ou le lot d'une autre marque que son brand_id répond 404 avec le code UNKNOWN_PRODUCT_REFERENCE, comme un identifiant qui n'existe pas.

Ce que vous faites. N'envoyez pas identity_level, ou envoyez "unit". Si un 409 MODEL_LEVEL_IDENTITY vous répond, passez le modèle au niveau unit par PUT /admin/product-models/{id}, puis renvoyez la même demande : un nouvel essai sans ce changement reçoit la même réponse.

L'exigence dépend de la catégorie : 46 données obligatoires pour un véhicule électrique, 49 pour un moyen de transport léger, 32 pour une batterie industrielle. Le score lit product_identity.battery_category et note sur la colonne correspondante.

Ce que vous faites. Le score d'un modèle batterie peut baisser, parce qu'il mesure maintenant ce que le règlement demande et non plus seulement ce que notre gabarit propose. Le cockpit liste les données manquantes avec leur numéro : c'est la même numérotation qu'une autorité emploiera.

⚠️ Quelques données obligatoires n'ont pas encore de champ chez nous. Elles ne sont ni comptées remplies ni comptées manquantes : le cockpit les affiche à part, comme un manque de notre côté.

Ce que vous faites. Rien, si vous appeliez cette adresse pour vos propres produits. Si votre intégration lisait la chronologie de produits d'une autre marque, elle recevra désormais la projection anonymisée.

C'est le même bloc, calculé par la même fonction, que celui que rend déjà GET /v1/passport/{identifier}. La fonction est la même, la version de passeport lue peut différer : /resolve est public et ne lit que les versions en visibilité public, tandis que /passport sert en plus les versions en visibilité owner_only au propriétaire actuel qui s'authentifie. Une unité qui porte une version owner_only peut donc recevoir deux niveaux de preuve différents selon le point d'entrée appelé. Pour tout autre appelant, les deux réponses portent la même version et le même niveau.

La réponse exacte. Le champ s'ajoute à la fin de l'objet, à côté de passport_anchor. Le bloc ci-dessous est celui d'un passeport qui décrit à la fois ses matières et ses substances préoccupantes.

{
  "evidence": {
    "sections": {
      "identity": "verified",
      "integrity": "verified",
      "composition": "declared",
      "substances_of_concern": "declared"
    },
    "legend": {
      "declared": "Stated by the brand. Recorded, dated and attributable, but not independently checked.",
      "verified": "Rests on an on-chain reference that anyone can re-check independently. SealTrust records it and does not re-query the chain on each request."
    },
    "derived": true,
    "note": "Statuses are computed by SealTrust from verifiable facts. A brand cannot set them."
  }
}

Il vaut null quand aucun passeport publié n'est servi, et null si son calcul échoue.

Quatre sections peuvent être notées, et aucune autre partie du passeport ne reçoit de mention. identity et integrity sont toujours là, parce qu'elles portent sur l'exemplaire lui-même. composition et substances_of_concern n'apparaissent que si les données du passeport les portent : sections compte donc de deux à quatre entrées selon l'exemplaire. Lisez les clefs présentes, n'en supposez aucune.

Ce que vous faites. Rien. Le champ s'ajoute, aucun champ ne change de sens et aucun appel qui passait avant ne casse. Un client qui ne lit pas evidence reçoit la même réponse qu'avant. Si vous décidez d'afficher ces mentions, n'en affichez que pour les sections que sections nomme, et ne recopiez pas ces valeurs dans votre base : elles sont recalculées à chaque lecture.

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.

Désormais, dès que votre réservation porte un état terminal, c'est elle qui décide : un lot dont aucune ligne n'a abouti répond status: "failed". Et les quatre compteurs batch_status, items_count, success_count et error_count sont présents dans toute réponse, dès le premier appel, alors qu'ils n'apparaissaient qu'une fois le lot oublié par la file.

Ce que vous faites. Fondez votre décision sur success_count et error_count. Si vous aviez suivi notre ancien conseil de ne pas regarder status: "failed", retirez cette exception : ce statut est désormais fiable.

Ce que vous faites. Si vous coupiez ces valeurs sur la virgule, comme cette documentation le conseillait, ce n'est plus nécessaire. Une lecture directe en nombre entier fonctionne.

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_live_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.