Changelog

The answer you receive now. These calls answer as on the Compliance + Identity offer. GET /timeline/{identifier} and GET /my-products carry identity_included set to true for these pieces. Creating a piece, ordering chip encoding and issuing a new purchase code still answer 403 OFFER_EXCLUDES_IDENTITY on the Compliance offer.

What you do. Nothing. If your integration hid the claim or the transfer based on the brand's offer, read the piece's identity_included instead.

The response you receive now. Without a token, POST /admin/mcp answers 401 with a WWW-Authenticate header that gives the address of the resource metadata. Claude follows that address, registers, then sends you to the "Connect an AI assistant" page of the console. A token is valid 30 minutes, a connection 90 days at most. Beyond 60 tool calls per minute per connection, the answer is 429 with a Retry-After header. A SealTrust team account cannot be connected. "Prepare drafts" is never ticked in advance, and changing or resetting your password ends your connections. The detail is in Connect the MCP server.

What you do. Nothing for an existing integration. To end a connection, open Settings, then Developers, "AI assistant connections" card.

The response you receive now. A 422 for a secret that is too short or empty, and for a null secret in a modification, with loc naming secret. A creation without a secret answers 201 with one more field, secret: this is the only time it is readable. A creation with your own secret does not return it, as before.

What you do. If your secret is under 32 characters, take a longer one. If you create without a secret, read the secret field of the response and configure it on your receiver. To keep the current secret in a modification, omit the field instead of sending null.

The response you receive now. After a secret change, the retries waiting their turn arrive signed with the new secret.

What you do. Nothing, if your receiver accepts both secrets during a switch, as this documentation advises.

The response you receive now. The transport is the Streamable HTTP of the MCP specification, without a session: each message is an independent POST, and a GET or a DELETE answers 405. A request carrying an Origin header from a site other than Claude or ChatGPT answers 403. Beyond 300 requests per minute per address, or 120 tool calls per minute per client, the answer is 429 with a Retry-After header. The detail is in Claude and ChatGPT in 30 seconds.

What you do. Nothing if you use the npm package: it does not change. For an online assistant, paste the address instead of installing anything.

• GET /partner/catalog/brands/{brand_code}/batches, one batch with ?batch_code= or the list of batches;
• GET /partner/catalog/brands/{brand_code}/passports/list, the latest version of each model and batch passport, without its content;
• POST /partner/catalog/brands/{brand_code}/passports/preview, what each audience will see of a draft, writing nothing;
• GET /partner/catalog/brands/{brand_code}/templates and GET /partner/catalog/brands/{brand_code}/templates/{template_key}, the passport templates.

The draft passport write accepts one more field, only_if_draft. Set to true, it only completes the open draft: a sealed or published latest version is refused with a 409, and no version at all with a 404.

The answer you receive now. The same answers as before on the existing endpoints. Without only_if_draft, a push on a sealed version still opens the next version.

What you do. Nothing. The detail is on the page Fill the catalog through the API.

The response you receive now. When a piece's media list holds no image, the model's cover image is added to it first, with the identifier 0, media_type set to image and the public address of the photo. A piece that has its own photo keeps exactly its list.

What you do. Nothing. If you took the first image of media as the thumbnail, it now appears. Do not look for the entry with identifier 0 in the brand's media library: it has no record of its own.

The response you receive now. When the calling account is the recorded holder of the piece, the response is 409 with detail "ALREADY_YOURS: you already own this product". Any other account receives exactly the response it received before: the piece has an owner, never which one.

What you do. Read the code before the colon. On ALREADY_YOURS, tell the person the product is already in their space, without sending them to the brand.

The response you receive now. These addresses answered 404. They now answer like GET /passport/{identifier}/vc and its two neighbours, with level (model or batch), gtin and, for a lot, batch_code in addition.

What you do. Nothing. To verify the passport of a model or a lot, call the new address.

The response you receive now. These three fields, when the passport carries them, in the public response.

What you do. Nothing.

The response you receive now. At the public tier, a textile's credential carries composition with the material and percentage of each row. It did not. A battery's credential no longer carries the part numbers, the battery status or the expected lifetime in cycles.

What you do. Nothing. A credential already issued keeps its disclosures; it is issued again at the passport's next publication.

The response you receive now. A badly written value gets a 422 whose detail.code is BRAND_REF_NOT_WELL_FORMED. detail.references says where the value is, without repeating it. In a batch sent as CSV, the faulty row is reported in the usual 400 refusal, and its message starts with BRAND_REF_NOT_WELL_FORMED. The whole batch is refused and nothing is created.

What you do. Send the number with digits only, 5 or "5", or better, the brand_code that GET /v1/partner/catalog/brands gives. If your code produces a decimal number, convert it to an integer before sending.

The response you now receive. Each code is shown once. A piece whose code was already used gets a 409 PURCHASE_CODE_ALREADY_USED, unless you send "replace_used": true. A piece of another brand gets the same 404 PIECE_NOT_FOUND as an unknown piece. The response of POST /partner/mint/batch carries a sixth field, issue_purchase_codes.

What you do. Nothing if you do not use purchase codes. Otherwise, tick claim_codes:issue on a dedicated key, never ticked by default, and read Issue purchase codes.

The response you receive now. The same valid field. message is "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." or "Unrecognised code: the QR signature or the on-chain record does not match.".

What you do. Nothing if you read valid, as this page asks. If you displayed message, never display "authentic" from this response.

The response you receive now. Sixteen fields instead of fourteen. Nothing else changes.

What you do. Nothing is required. If you displayed verified_at as a verification date, read registered_at and write "registered on": nobody verified the object on that date.

The response you receive now. A PDF whose seal and footer have new text. The rest of the document is unchanged.

What you do. Nothing, unless you compare the PDF's text with an expected value.

The response you now receive. The answers of the partner API, of the partner portal, of /sdm/verify and of the public keys that returned brand_id also return brand_code. brand_id is deprecated there. A code that names no brand gets the same 403 as a brand the key does not serve. A request that sends brand_code and brand_id together is refused: with 422 for a sale or a subscription, with 400 for a batch row.

What you do. Nothing right away: the brand_id number is still accepted everywhere it was. Replace it with brand_code at your next change. GET /brand/{brand_id}/did.json keeps the number, because it is part of the did:web identifier already signed into the issued credentials.

The response you now receive. An address whose code names no brand gets the same 404 as a brand without an active connector. The address that carries the brand's number keeps working.

What you do. Nothing: an address already pasted into your ERP keeps working. For a new connector, paste the address the console shows.

The response you now receive. brand_id is deprecated there. GET /my-products accepts the ?brand_code= filter.

What you do. Nothing right away: brand_id is still returned. Read brand_code at your next change. If you read the export by column position, shift every column that follows brand_id by one.

The response you now receive. A materials block may appear in data at the public tier. The origin of the materials is not part of it.

What you do. Nothing. If you showed "composition restricted" for want of materials, show the block when it is there.

The response you now receive. composition appears only when a material row carries at least a name, a share or an origin. Otherwise the key is absent from sections, as for a passport with no materials. A figure the brand left empty is never returned as 0.

What you do. Nothing. Treat a missing composition as you already do: the brand declared nothing.

The response you receive now. An address ending in .photo.webp: a WebP image of 800 pixels at most on the long side, 100 KB at most, with no EXIF data. A photo that has no copy yet keeps the address of the original; an address of another site is returned as given. The field changes neither name nor type, and null keeps its meaning.

What you do. Nothing. If your integration inferred the file format from the extension of the address, read the Content-Type header of the response instead.

The response you receive now. On a paid plan, a batch sent to POST /v1/partner/mint/batch no longer receives the 403 whose detail.code is QUOTA_EXCEEDED and detail.resource is products. It is accepted. A trial account still receives that refusal, with "period": "monthly".

What you do. Nothing. If your integration waited for that refusal to spread its submissions from one month to the next, you can remove that wait.

The response you receive now. A batch whose rows carry the brand_id of one of your client brands is accepted. The sale and the subscription take an optional brand_id field, and the subscription list a brand_id parameter. A brand the key does not serve still receives a 403, whose detail is now "This API key cannot act for this brand." (the "Brand mismatch: ..." text is gone). A batch that mixes several brands receives a 422 whose detail.code is ONE_BRAND_PER_BATCH.

What you do. Nothing if you did not read the refusal text. If your integration compared it to "Brand mismatch", compare the 403 code instead. With a reseller key, you may retire the keys created on your client brands: the details are on the page Fill the catalog through the API.

The response you receive now. image_url is the full address of the model's photograph, computed the same way at all three levels: its main photo, or else the first image of its media library. null when the model has none. On the passport of a piece, three cases change: a photo recorded as a bare storage path now arrives as a full address, a model with no main photo shows the first image of its media library instead of null, and a model of a brand other than the passport's answers null.

What you do. Nothing: it is one more field. Show it if your page shows the product.

The response you receive now. For a brand on the compliance offer, every operation on a piece answers 403, with detail.code equal to OFFER_EXCLUDES_IDENTITY and detail.feature saying what was refused: creating pieces with POST /v1/partner/mint/batch, reading a chip with POST /v1/partner/nfc/verify, declaring a sale with POST /v1/partner/sellout, and the same operations in the console. Nothing is written, queued or sent to the blockchain.

What you do. Nothing for a brand that does not change offer. For a brand on the compliance offer, do not replay a call refused with this code, and print the QR code of its model or its lot. The details are on the page Compliance, or Compliance + Identity.

The response you receive now. 200 and a PNG image for such a brand. In every other case, the same response as before: 410 with detail.code equal to ITEM_QR_ONLY.

What you do. Nothing if your brands are on the compliance_identity offer: they still print the code of every piece.

The response you get now. The status stays 200 and the image stays a PNG. For a brand whose domain is verified but not final yet, the encoded address starts with https://sealtrust.io instead of the brand's domain. That address stays valid forever.

What you do. Nothing. If you print these codes for a brand that wants its domain on its labels, the brand first makes its domain final from its console, by exporting the QR codes of a batch.

The response you now receive. The code stays 200. Without authentication, available_tiers is ["public"]. The list grants nothing: every tier asked is still checked, with the same refusals as before.

What you do. Nothing. If you offer your users a choice of tier, offer the tiers of this list, and only them. A response made for a signed-in account must go to no shared cache.

The response you now get. The status stays 200. In passport.data, the environmental impact, repairability index, expected lifetime, durability, energy efficiency, carbon footprint, primary material, care and movement no longer appear. The recyclability rate and the recycled content stay. The evidence block does not change.

What you do. If your integration displays those fields, read them on GET /passport/{identifier} with an account session token in Authorization: Bearer. If you display them when they are missing, show an absence, never a zero: a missing value is not a zero value.

The rule holds for the six endpoints that take access_tier: GET /passport/{identifier}, GET /passport/01/{gtin}, GET /passport/{identifier}/vc, GET /passport/{identifier}/vc/preview, GET /passport/{identifier}/vc/verify and GET /passport/01/{gtin}/10/{lot}.

The response you now get. A call with no session at the end_user tier gets 401, with detail equal to End-user-tier access requires authentication. The public tier does not change.

GET /resolve/{identifier} takes no access_tier parameter. It serves the public tier, see the previous entry.

What you do. If your integration asks for end_user without a session, present an account session token in Authorization: Bearer, or ask for the public tier. A partner API key is not a session and does not open this tier.

The exact response. These requests now answer 404, detail is Produit introuvable, exactly as for a made-up identifier. On the own domain of a brand, the portal finds the products of that brand only. The 403 Aucune accréditation active does not change.

What you do. If your code handles this 403 separately, handle the 404 instead: the product is outside your scope, or it does not exist.

The exact response. Such an account receives 403 on GET /v1/passport/{identifier}, GET /v1/passport/01/{gtin}, GET /v1/passport/01/{gtin}/10/{lot} and on the three verifiable credential endpoints, with the usual detail of that refusal. A repairer keeps the repairer tier, and a recycler the recycler tier.

What you do. Nothing if you call with an administrator or partner account. Otherwise, ask the brand for the role that matches your use.

• GET /partner/passports/{identifier}, GET /partner/passports/01/{gtin} and GET /partner/passports/01/{gtin}/10/{lot} return the passport, its proof and its signature in one call.
• POST /partner/scans and POST /partner/nfc/verify count each scan for the visitor named by four signed headers, and no longer for your server.
• GET /partner/nfc/receipts/{receipt} reads a chip read our page has already verified: the chip is verified only once.
• POST /partner/nfc/verify answers 503 NFC_READ_IN_PROGRESS, with Retry-After, to a retry that arrives while your first call is still verifying the same read, instead of taking it for a copy.
• Our /claim and /transfer pages accept serial and return and send the visitor back to your page, with claim_outcome or transfer_outcome. GET /my-products now carries the serial field.

A reseller key also acts for the client brands on these six endpoints.

When a brand switches it on in the console, /p/{serial}, /01/{gtin}/21/{serial}, /01/{gtin} and /01/{gtin}/10/{lot} answer 302 to the partner's page, and GET /sdm/verify-url carries a partner_redirect_url field. Without that setting, these answers do not change, and the field is null.

What you do. Nothing for an existing integration. To show the passports in your page, read Show the passport in your page.

• GET /01/{gtin}/10/{lot}, the GS1 link of the batch, which answers 302 to the page of the batch's passport, or to the model's when the batch has no published passport yet;
• GET /v1/passport/01/{gtin}/10/{lot}, the batch's passport, with "level": "batch", product_batch_id and batch_code;
• GET /v1/passport/01/{gtin}/10/{lot}/proof, its proofs. Its anchoring on chain comes from the same sweep as the other passports, without any minting.

A unit with no passport of its own now receives the one of its batch when it has one, before its model's, on GET /v1/passport/{identifier}, its proof, its verification, GET /v1/resolve/{identifier} and the partner portal.

What you do. Nothing: no existing response changes as long as no batch passport is published. If your integration reads product_id: null as "model passport", read instead the level field of the shared level responses, which is model or batch.

Three rules protect batch labels already printed:

• the GTIN of a model whose batch has a published passport no longer changes: PUT /admin/product-models/{id} answers 409, and the Excel import refuses the row;
• a GTIN belongs to one brand, at every level: publishing a model or batch passport under a GTIN that another brand already publishes, through its model or one of its batches, answers 409;
• publishing a batch draft whose batch was renamed since answers 422.

The reversibility archive writes for each passport its level, its product_batch_id and its batch_code.

A reseller key also acts for the client brands attached to the reseller contract, on these seven endpoints only.

Every returned batch carries lot_passport_blocker: null when its code can carry a lot passport, otherwise the reason (more than 20 characters, or a character the GS1 link refuses). The batch is created all the same.

Four scopes that opened no endpoint are no longer offered when a key is created: mint:single, products:read, products:status and transfers:create. A key that already carries one keeps working exactly as before, since that scope opened nothing.

What you do. Nothing for an existing integration. To pre-fill your catalog, create a key carrying catalog:write and read Fill the catalog through the API.

The response you get now. GET /qr/01/{gtin}, GET /qr/01/{gtin}/download, GET /qr/01/{gtin}/10/{lot} and GET /qr/01/{gtin}/10/{lot}/download answer 410, with detail.code equal to ITEM_QR_ONLY. The response is the same for every GTIN and every batch, known or not. The links /01/{gtin} and /01/{gtin}/10/{lot} themselves do not change: a code already printed still leads to its passport.

What you do. Draw each unit's code with GET /qr/product/{serial}/download. The page of each unit shows the passport of its batch, or else the passport of its model.

• POST /admin/product-models and PUT /partner/catalog/brands/{brand_id}/models create a model at unit level, whether the body gives the field or not. Connectors and the Excel import also create at unit level. Sending "identity_level": "model" answers 422.
• A model still at model level gets no unit: /mint, /mint/batch, /admin/batch/mint, /admin/batch/prepare and /admin/batch/prepare-mapped answer 409 with the code MODEL_LEVEL_IDENTITY, before anything is written, whether the row names the model or only its batch. The detail gives identifiers only.
• A row that names the model or the batch of a brand other than its brand_id answers 404 with the code UNKNOWN_PRODUCT_REFERENCE, like an identifier that does not exist.

What you do. Do not send identity_level, or send "unit". If a 409 MODEL_LEVEL_IDENTITY answers, switch the model to unit level with PUT /admin/product-models/{id}, then send the same request again: a retry without that change gets the same answer.

The requirement depends on the category: 46 mandatory data points for an electric vehicle battery, 49 for a light means of transport, 32 for an industrial one. The score reads product_identity.battery_category and marks against the matching column.

What you do. A battery model's score may drop, because it now measures what the regulation asks for and no longer only what our template offers. The cockpit lists the missing data points with their number: that is the same numbering an authority will use.

⚠️ A few mandatory data points have no field with us yet. They are counted neither as filled nor as missing: the cockpit shows them separately, as a gap on our side.

What you do. Nothing, if you were calling this address for your own products. If your integration was reading the timeline of another brand's products, it will now receive the anonymized projection.

It is the same block, computed by the same function, as the one GET /v1/passport/{identifier} already returns. The function is the same, the passport version read can differ: /resolve is public and reads only the versions whose visibility is public, while /passport additionally serves the owner_only versions to the current owner when that owner is authenticated. A unit that carries an owner_only version can therefore receive two different levels of proof depending on the endpoint called. For every other caller, both responses carry the same version and the same level.

The exact response. The field is added at the end of the object, next to passport_anchor. The block below is the one of a passport that describes both its materials and its substances of concern.

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

It reads null when no published passport is served, and null if its computation fails.

Four sections can be rated, and no other part of the passport receives a status. identity and integrity are always there, because they bear on the unit itself. composition and substances_of_concern appear only when the passport data carries them, so sections holds two to four entries depending on the unit. Read the keys that are there, assume none.

What you do. Nothing. The field is added, no field changes meaning and no call that worked before breaks. A client that does not read evidence receives the same response as before. If you decide to display these statuses, display one only for the sections that sections names, and do not copy these values into your database: they are recomputed on each read.

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.

Now, as soon as your reservation carries a terminal state, it decides: a batch where no line went through replies status: "failed". And the four counters batch_status, items_count, success_count and error_count are present in every reply, from the first call on, where they used to appear only once the queue had forgotten the batch.

What you do. Base your decision on success_count and error_count. If you followed our old advice not to look at status: "failed", drop that exception: the status is reliable now.

What you do. If you were splitting these values on the comma, as this documentation advised, you no longer need to. Reading them straight as an integer works.

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