# Make your products verifiable By the time you leave this page, you will know what SealTrust does for your brand and where to find the answer to your question. Source: https://docs.sealtrust.io/en/ --- By the time you leave this page, you will know what SealTrust does for your brand, which route to take to make your products verifiable, and which page to go to depending on the question you have. ## What SealTrust does for your brand SealTrust attaches a verifiable identity to your physical products. You register your products from your brand console, at `admin.sealtrust.io`. Every unit receives, when it is created, a public twelve-character identifier drawn at random. The QR code applied to the product encodes the address that contains this identifier, `https://sealtrust.io/p/{serial}`. You also create products in batches through the partner API. This route only creates units identified by QR. The server itself sets, on each line of the batch, the identification method and the technical identifier of the product, and your submission carries neither of them. For units with an NFC chip, go through the console. The [Create products](/en/creer-des-produits/) page details what this endpoint accepts and rejects. A customer scans this QR code with the camera of their phone. They land on a web page that answers three questions: is it authentic, which product is it, where is the proof. A link leads to the ownership history, where the holder's email address appears masked. The customer has no account to create and no app to install. Alongside it you publish the digital product passport, the document required by the European ecodesign regulation, known as ESPR. The regulation allows three levels: the model, the batch and the item. SealTrust serves two of them. - At the model level, at `https://api.sealtrust.io/v1/passport/01/{gtin}`. This passport covers every unit that shares the same GTIN product code. - At the item level, at `https://api.sealtrust.io/v1/passport/{identifier}`. The level of detail returned by default is the public level defined by the ESPR. SealTrust anchors certain batches of products on the Base chain, chain_id 8453. We trigger this anchoring batch by batch. Your brand does not trigger it itself, and most products are never anchored. You request the proof that a product belongs to an anchored batch, publicly and without an account, at `https://api.sealtrust.io/v1/verify/merkle/{identifier}`. > [!INFO] A 404 on the anchoring proof is not a failure > A product whose batch has not been anchored gets a 404 on > `/v1/verify/merkle/{identifier}`. That response says that the product is not > part of an anchored batch. Treat it as such. It says nothing against the > authenticity of the product, which is verified through the other endpoints. A product can also carry a certificate of authenticity. You read it at `https://api.sealtrust.io/v1/certificate/{identifier}`. The QR code alone is enough to identify and verify a product. You add an NFC seal when you want a proof of originality carried by the chip itself. You verify the signature of that chip with `POST https://api.sealtrust.io/v1/originality/read-sig/verify`. > [!INFO] QR alone is a mode in its own right > Nothing on this site assumes that your products carry an NFC chip. The QR > journey is complete on its own: identification, verification page, passport, > anchoring proof and certificate. ## Where to start This site is organized so that a question finds its answer on a single page. Choose the section that matches your question. ### Quickstart You want to see the system work before deciding anything. The [Quickstart](/en/demarrage-rapide/) page follows the shortest path to your first verifiable product. Two pages go with it in the Start here section. [Core concepts](/en/notions/) defines the vocabulary used everywhere else: product, model, batch, item, certificate, passport, seal. [Physical identification](/en/identification-physique/) compares QR and NFC and says what each one brings. ### Guides You want to understand a subject from end to end. A guide tells a journey and is read in full. There are seven of them. - [Getting started with the console](/en/console-prise-en-main/) - [Create products](/en/creer-des-produits/), one at a time and in batches - [Digital Product Passport](/en/passeport-dpp/) - [NFC seal engraving and encoding](/en/gravure-sceaux-nfc/) - [Receive events by webhook](/en/webhooks/) - [Regulatory compliance](/en/conformite/) - [Trust and proofs](/en/confiance-et-preuves/) ### Reference You have a precise question and you want to be on your way in ten seconds. The reference is never read in full. It gives one page per endpoint, always with the same structure: authorization required, call limit, parameters, request body, copyable example in curl, TypeScript and Python, real response, and a table of errors. Start with [the partner API overview](/en/api-vue-ensemble/). It explains how to authenticate your calls and where to find the rest. The key-authenticated partner API has eight endpoints, served at `https://api.sealtrust.io`. Five manage your webhooks, one reports a sale to the end customer, and two concern item batches, the one that submits a batch and the one that tracks its progress. The `/v1` prefix is the form to use for a new integration. The reference also documents three other sets. - The [table of API errors](/en/api-erreurs/), common to every key-authenticated endpoint. - Four partner portal endpoints, reserved for repairers and recyclers accredited by a brand. They authenticate with the session of a partner account, and an API key gives no access to them. See [GET /partner-portal/me](/en/reference/get-partner-portal-me/). - Twenty-one public endpoints, which require no account: verification, passport, GS1 Digital Link, verifiable credential and NFC originality. See [GET /resolve/{identifier}](/en/reference/get-resolve/). Four reference pages to start with. - [GET /resolve/{identifier}](/en/reference/get-resolve/) returns in a single call everything a product page displays: identity, certificate, published passport, media, history and anchoring proofs. No API key is required. - [GET /passport/{identifier}](/en/reference/get-passport-identifier/) returns the published digital passport of a single product, at the requested access level. - [GET /certificate/{identifier}](/en/reference/get-certificate/) returns the certificate of authenticity of a product and its status. - [GET /partner-portal/me](/en/reference/get-partner-portal-me/) returns the profile of the signed-in partner and the list of brands that have accredited them. To these are added the [TypeScript SDK](/en/sdk-typescript/), the [mobile SDK](/en/sdk-mobile/), the [MCP server](/en/mcp/), the [plans and limits](/en/offres-et-limites/) and the [changelog](/en/journal-des-changements/). > [!ATTENTION] Your plan governs what is open to you > Access to the API and the sending of webhooks depend on the plan your brand > has subscribed to. A call refused for that reason returns an explicit error. > The [Plans and limits](/en/offres-et-limites/) page summarizes what each plan > includes. ## The values in the examples The values that appear in the examples on this site are invented and obviously false. The brand is called `Exemple SAS`, the GTIN is `03701234567890`, the API key is `st_test_0000000000000000000000000000000000000000000000`. No customer identifier, no real product reference and no usable secret appears in this documentation. A single value on the site escapes this rule, and it is flagged where it appears. The page [POST /originality/read-sig/verify](/en/reference/post-originality-read-sig-verify/) uses as an example a genuine public constant, the generator point of the P-224 curve, published in the standard that describes this curve. A real point on the curve was needed for the example to go all the way through the cryptographic check. This constant is the key of no manufacturer and opens no access.