Changelog

Six tiers remain: public, end_user, repairer, recycler, upstream and authority. The three trade tiers are distinct audiences: holding one accreditation opens none of the others.

The exact response. ?access_tier=value_chain now answers 422, on GET /v1/passport/{identifier}, on GET /v1/passport/01/{gtin} and on the three verifiable credential endpoints. detail is the usual validation list, each entry carrying loc, type and msg, and loc names access_tier.

What you do. Ask for your own trade's tier, repairer or recycler. You will receive fewer fields than before, and they are precisely the fields that are not part of your trade.

What you do. If your code compares this value to value_chain, revisit the comparison. And expect narrower content than before: it is now filtered on your accreditations alone.

What you do. Nothing. A field that used to read null may now carry an address.

Three surfaces are affected: GET /v1/certificate/{identifier}, the PDF returned by GET /v1/certificate/{identifier}/download, and the certificate block of GET /v1/resolve/{identifier}.

What you do. Nothing in your calls. If you copied the value of issuer_name into your own database, replace it with what the API returns today.

Two refusals from POST /v1/originality/read-sig/verify follow the same rule and now read Invalid uid_hex and Invalid signature_hex.

What you do. Nothing, if you key your code on the HTTP status code, as the errors page recommends. A client that compares these sentences character by character must revisit those comparisons, or better, remove them.

Every accepted response carries X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset. Going over returns 429, with detail reading Rate limit exceeded: 30 requests per 60s and a Retry-After header reading 60.

What you do. Space out your calls to the portal and drive your pace from X-RateLimit-Remaining. A human journey, searching for a product then reporting an intervention, stays well below this limit.

The server now sets those two values itself, on every row: the identification method qr and the product's technical identifier.

What you do. Nothing in your submissions. A row's contract does not change, and a row that carried the identification method or the technical identifier is rejected with 400, like any field the contract does not name.

Products created this way are identified by QR. For NFC items, go through the console.

The API used to accept these two fields and never read them. The value you put in them had no effect.

A batch row now accepts five fields and nothing else: product_name, brand_id, category_id and metadata_uri, which are required, and external_ref, which is optional.

What you do. Remove these two columns from your CSV exports and these two keys from your JSON objects. If you need to tie a row to a reference on your side, use external_ref: it is the contract's only free field. We keep it on the batch row and we return it in the result read by GET /v1/partner/mint/batch/status/{job_id}. No product field picks it up.

Removing them makes validation pass. Since August 21, 2026, it also makes the products get created, see the entry for that date.

Replaying the same value with the same batch still returns the first call's response, without minting anything again. The order of the checks changed the same day. A replay now consumes a token from your rate limit, and the API re-reads your request body before returning the cached response. A replay beyond the limit therefore receives 429. A replay whose body has become unreadable receives 400.

Replaying the same value with a different batch now answers 409. The API does not queue your second batch, and the response tells you so.

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

The same 409 code also signals that a call carrying this key is still being processed. The message is then A request with this Idempotency-Key is already being processed. Read the message before deciding what to do: the first case asks you to change your key, the second asks you to wait for the processing under way to finish.

Two batches are compared on their content once read. Row order, column order, the choice between CSV and JSON, and empty cells make no difference.

What you do. Build one Idempotency-Key value per distinct batch. If your code reuses a fixed value, or a value derived from the time to the minute, change it now.

What you do. Check that the key querying the tracking endpoint carries mint:batch. A key's scopes are set when it is created and no screen changes them afterward, so you need a new key.

First check your key limit, which counts only active keys. The Essentiel plan allows only one: revoke the old key, then create the new one, accepting the outage between the two. The Prestige plan allows five: create the new key, deploy it, then revoke the old one. Revoking a key frees a slot immediately. A creation beyond the limit answers 403 with the QUOTA_EXCEEDED code.

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

Turning one off is the one exception: sending is_active at false and nothing else remains possible without the plan. As soon as another field accompanies that switch off, the API requires the plan.

Creating a subscription, POST /v1/partner/webhooks, answers the same thing and already required it before this change.

What you do. Nothing if your plan includes notifications. If it no longer includes them, stop changing your subscriptions: turn them off with is_active at false alone, or delete them.

{
  "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."
}

What you do. If your code automatically replays responses in the 5xx family, this case no longer triggers it. A request rejected with 400 must be fixed, and replaying it as is will give the same refusal.

Two visible consequences. Beyond the limit, you receive 429 with the Retry-After header, expressed in seconds. When the rate limiting service is unavailable, you receive 503, and the call has no effect: a deletion refused this way deletes nothing.

Responses that go through carry X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset and X-RateLimit-Scope.

What you do. Read X-RateLimit-Remaining and slow down before you reach zero. If you poll a batch's tracking endpoint in a loop, space out your calls: it is the endpoint most exposed to this limit. Treat the 503 as a temporary outage and retry after a delay.

Sending notifications follows another rule: a brand whose plan no longer includes notifications receives no more deliveries, whatever subscriptions are still recorded.

What you do. Nothing. If your plan no longer includes notifications, you keep control to inventory your subscriptions and to delete them.

No end-of-service date is attached to these addresses. If your integration already calls them, it keeps working.

What you do. Nothing right now. Use the /v1 form for any new integration: it is the form documented everywhere on this site.

A gzip file the server cannot decompress now answers 400, with the reason in the message. It is a request error, and your code can treat it as such.

A file whose decompressed content exceeds the limit answers 413, and the message states that limit in MiB.

What you do. Nothing if your submissions are valid. If you compress on the fly, check that the stream is complete before sending it, and split your batches to stay under the limit. A batch carries at most 500 items.

An identifier that designates no batch of your brand still answers unknown, revealing nothing more.

What you do. Nothing, these fields are additions.

The request body accepts an optional proof_code field. Without it, the level reads declared. With a valid code, it reads customer_code when the code was read by the customer, or work_order when it comes from the brand's work order. A rejected code answers 422 and records nothing at all: neither the intervention, nor the consumption of the code.

Interventions recorded before this date return proof_level empty. An empty value does not mean declared: the question had not been asked.

What you do. If you display the intervention history, treat the empty value as a separate case and do not display "declared" in its place.

Without that parameter, a subscription that belongs to you answers 400 with the CONFIRMATION_REQUIRED code. With a value that does not match, the response is 400 with the CONFIRMATION_MISMATCH code, and the API changes nothing. A successful deletion answers 204.

An identifier that designates no subscription of your brand answers 404, whether you sent confirm or not: the API looks for your subscription before looking at your confirmation.

A call that sent only the identifier is therefore rejected.

What you do. Read the address with GET /v1/partner/webhooks/{webhook_id}, then send it back in 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"

What you do. Nothing, this header is an addition.

X-Webhook-Id is the hash of the delivery body. Retries of the same delivery carry the same value, which lets you discard a retry. Two distinct events whose body is identical also carry the same value.

What you do. Deduplicate on the pair formed by the event name, carried by X-Webhook-Event since August 11, 2026, and X-Webhook-Id. Never discard a delivery on the value of X-Webhook-Timestamp: that timestamp changes with every retry, so it would make you process the same delivery twice.

The signed body is the byte sequence received on the wire. Decoding the JSON then re-encoding it before verifying breaks the signature, because re-encoding does not produce the same bytes.

What you do. Verify the signature on the raw request body, before any decoding.

A key that does not carry the scope receives 403, and the message names the missing scope.

What you do. Check the scopes of the key that manages your subscriptions. If it was created with the mint:batch scope alone, create a new key that also carries the notification scopes.

The prefix-free addresses additionally answer two headers, Deprecation: true and Sunset: 2026-09-01. The /v1 addresses do not carry them. The August 16, 2026 entry removes these two headers and no end-of-service date was ever applied.

What you do. Nothing. Both addresses call the same code.