Make your products verifiable

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

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.

#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 page follows the shortest path to your first verifiable product.

Two pages go with it in the Start here section. Core concepts defines the vocabulary used everywhere else: product, model, batch, item, certificate, passport, seal. Physical identification 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
• Create products, one at a time and in batches
• Digital Product Passport
• NFC seal engraving and encoding
• Receive events by webhook
• Regulatory compliance
• Trust and proofs

#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. 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, 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.
• Twenty-one public endpoints, which require no account: verification, passport, GS1 Digital Link, verifiable credential and NFC originality. See GET /resolve/{identifier}.

Four reference pages to start with.

• GET /resolve/{identifier} 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} returns the published digital passport of a single product, at the requested access level.
• GET /certificate/{identifier} returns the certificate of authenticity of a product and its status.
• 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, the mobile SDK, the MCP server, the plans and limits and the changelog.

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