Compliance, or Compliance + Identity

When you leave this page, you will know which offer a brand is on, what that offer allows, what the API answers when an operation is not included, and what happens when a brand changes offer.

#Two offers, one per brand

Every brand is on one of these two offers.

The Compliance offer covers the product passport that regulation asks for. The passport is carried by the model or by the lot, and the brand prints the QR code of that model or lot on its products. Every product of the same model carries the same code.

The Compliance + Identity offer adds the identity of every piece: one token per piece, one QR code per piece, and everything that follows from it for the person who buys the product.

A brand created with nothing more said is on the Compliance + Identity offer.

#Reading a brand's offer

The brand reads its offer in the answer of GET /plan/status, in the offer field. The includes_identity field is true on the Compliance + Identity offer and false on the Compliance offer.

On the Compliance offer, the same answer carries no quota of pieces, certificates or chips (quotas.products, quotas.certificates and quotas.tags are absent), no piece price (pricing.included_pieces_per_year and the pricing.per_product_* fields are null), no price per passport (pricing.per_dpp_addon_cents is null), pricing.auth_methods_allowed is "qr" and features.nfc_encoding is false: it describes what the brand can do, offer included.

{
  "offer": "compliance",
  "includes_identity": false
}

#Who sets the offer

• The SealTrust team (superadmin) sets the offer of any brand.
• A reseller sets the offer of the client brands of its contract, from the Your client brands tab, where it is called the scope. It also picks it when it opens a client brand. Its platform can also set it through the API, with a reseller key: see Fill the catalog through the API.
• The brand itself reads its offer and does not change it: the offer is what it bought.

Every change is written to the audit log, with its author, the offer before, the offer after and the number of pieces kept.

#What the API answers when an operation is not included

On the Compliance offer, every operation on a piece is refused before anything is written, queued or sent to the blockchain. The answer is always the same.

{
  "detail": {
    "code": "OFFER_EXCLUDES_IDENTITY",
    "offer": "compliance",
    "feature": "transfer",
    "message": "This brand is on the compliance offer, which does not include transferring a piece. It covers the product passport by model or by lot, and its QR code. The offer 'compliance_identity' includes the identity of every piece."
  }
}

The HTTP status is 403. The feature field says what was refused:

Do not replay a call refused with this code: it is refused the same way for as long as the brand stays on the Compliance offer.

The QR code of a piece already created, kept from a Compliance + Identity period, is still served by GET /qr/product/{serial} and /download: it leads to the page of the piece, which stays readable.

#The QR code of a model or a lot

A brand on the Compliance offer prints the QR code of its model or its lot.

• GET /qr/01/{gtin} draws the code of the model, which encodes /01/{gtin}.
• GET /qr/01/{gtin}/10/{lot} draws the code of the lot, which encodes /01/{gtin}/10/{lot}.
• The same addresses followed by /download return the same PNG as a download. The file name carries the GTIN and, for a lot, the lot number: two lots of one model never download under the same name.

The code is drawn only when the passport of the model or the lot is published. It carries the brand's domain once that domain is final, our address before.

In every other case, these four addresses answer 410 with the code ITEM_QR_ONLY: a brand on the Compliance + Identity offer prints the code of every piece, and a passport that is not published has no code yet. The answer is the same for a GTIN that names nothing.

Codes already printed under /01/{gtin} and /01/{gtin}/10/{lot} still lead to their passport, whatever the offer.

#In the console

The console reads the offer of the brand on screen. On the Compliance offer:

• the menu entries that only serve the identity of pieces stay visible, dimmed, marked "Identity" and followed by a padlock: products waiting to be minted, create a product, certificates, claim rules, returns, buyback, and the NFC "Tools" section. The click opens an email to talk to us about it instead of the screen;
• the command palette does not offer these screens;
• no mint or encoding button appears, whatever the account;
• the page of a model and the page of a batch show the QR code to print, once the passport is published;
• the dashboard, the start-up list, the top bar and the choice of path offer nothing that leads to a piece: no mint, no NFC, no claim funnel, no count of pieces;
• the page of a batch offers neither to attach nor to add units, the empty product list does not offer to mint one, and the guided tour skips the certificates step;
• a screen reserved for identity, opened from a saved link or a typed address, shows "Included in the Compliance + Identity offer" instead of its content;
• if the API refuses an operation anyway, the message is shown in the console's language.

As long as the offer is not known, for example when the server does not answer, the console takes nothing away: the server is what applies the offer.

#On the public page of a piece

A brand moved to the Compliance offer keeps its pieces. Their public page still shows their passport and their history, but no longer offers to claim or transfer them. GET /timeline/{identifier} says so in the identity_included field, set to false.

In the space of the person who holds such a piece, the product page offers neither the transfer nor the repair request. GET /my-products carries the same identity_included field for each piece. If the call is made anyway, the site shows a sentence in the page language, never the API's technical message.

On the passport of a brand on the Compliance offer, the "Access levels" section names neither an owner nor an NFC chip: the public tier is read through the product's QR code. GET /brands/{brand_code}/branding carries the includes_identity field, set to false on that offer.

#What is counted

A brand on the Compliance offer is counted by the number of its passports: the products online during the year, the lots created, and piece passports only when a regulation requires them. That piece passport, without a token, is not offered yet: no piece can be created on this offer, and that counter stays at zero. Scans are never counted for billing. A reseller finds these counters every month in the usage statement of its client brands.

Since September 2026, a brand on the Compliance + Identity offer is counted the same way, and its pieces are added: the Compliance + Identity offer costs the Compliance price of its catalogue, plus its pieces.

#The scans of your codes

Every scan of the QR code of a model or a lot is counted, per code and per month. It is never billed: it is read next to the fair-use threshold set in the contract, and beyond that threshold we talk it over with you. Only the visits of a person who arrives through the code are counted: no robots, no link previews.

• A reseller's usage statement shows, for each client brand on the Compliance offer, the scans of the month, those of the year and the year's threshold.
• The brand reads them for one month with GET /admin/passport-scans?brand_id={id}&month=YYYY-MM (console session). The answer gives the total and one row per code: level (model or lot), gtin, lot and scans.
• The current month is provisional: the latest scans join it within a few minutes.

#Changing offer

A change of offer never deletes anything, in either direction. The offer decides what can be done from now on, not what exists.

From Compliance to Compliance + Identity. Always possible. The model and lot passports stay what they are, and their printed codes keep working. The brand can create pieces from now on.

From Compliance + Identity to Compliance. Possible, and every piece already created is kept: its token, its owner, its history and its page. From now on, no piece is created, and no operation is done on the existing pieces: no claim, no transfer, no NFC reading, no lifecycle. Their page stays readable.

An operation started before the change does not finish after it. A transfer waiting for its code, a return not yet signed, a buyback offer not yet accepted, a sale declared on a piece already activated, an edit of an existing warranty and a new purchase code for a piece that already had one all receive the same 403 refusal. The old code stays as it was, with the date it was used.

Because this change stops something the brand's customers may be using, a brand that has pieces must confirm it. So must a brand with mint batches not finished (queued, prepared, running or waiting for a retry): once the brand is on the Compliance offer, such a batch creates no piece, and its rows end refused with OFFER_EXCLUDES_IDENTITY. A batch already running stops at its next piece or group: the offer is read again before every send, and only the send already on its way when the change lands goes through. Without the confirmation, the answer is 409, with the number of pieces and of batches concerned:

{
  "detail": {
    "code": "OFFER_CHANGE_NEEDS_CONFIRMATION",
    "pieces": 3,
    "batches_in_flight": 0,
    "message": "This brand has pieces, or mint batches not finished. On the compliance offer every piece is kept, but no claim, transfer, NFC reading or lifecycle operation can be done on them, and a batch not finished creates no piece. Send the same request with confirm_pieces_kept=true to confirm."
  }
}

The console then shows the number of pieces kept, the batches not finished, and a confirmation button, under the choice of offer.

Going back. Going back to the Compliance + Identity offer restores everything, since nothing was deleted.

Setting the offer the brand already has changes nothing and writes nothing.

Every change is kept with its date. A reseller's monthly statement counts each month with the offer the brand had on the first day of that month: a change never alters a month already past. Pieces created after a move to the pack during a month are priced in that same month, at the pack price.

#What to remember

• Every brand is on compliance or on compliance_identity, and the brand reads it in GET /plan/status.
• On compliance, every operation on a piece answers 403 OFFER_EXCLUDES_IDENTITY, and nothing is written.
• On compliance, the brand prints the QR code of its model or its lot.
• A change of offer deletes nothing. Towards compliance, a brand that has pieces, or mint batches not finished, confirms the change.