GETMethod GET/passport/{identifier}/verify

You check that a published passport has not been modified since its publication. By the end of this page, you will know how to ask for this check from any item identifier, how to read the three verdicts the response returns, and how to tell an altered passport from a check that could not complete.

Full address:

GET https://api.sealtrust.io/v1/passport/{identifier}/verify

The same endpoint also answers without the /v1 prefix, at https://api.sealtrust.io/passport/{identifier}/verify. The two addresses call the same code. Use the /v1 form for a new integration.

#Authorization

None, this is a public endpoint. You send no API key, no session and no origin header. The response is the same for everyone.

#Rate limit

60 calls per 60-second window, counted by calling network address.

This counter is shared by every path that starts with /passport. The calls you send to one of them therefore eat into the budget of the others. The /v1 prefix does not create a second budget: /v1/passport/0ABCDEFGHJKM/verify and /passport/0ABCDEFGHJKM/verify fill the same counter.

Plan for a timeout of at least 30 seconds on the client side. During your call, this endpoint goes to fetch the immutable public copy from public gateways. It queries several of them one after the other, each with its own time limit, so a first call on a copy the server has never read yet can last some twenty seconds. The calls that follow on the same copy answer without going to fetch it again. When no gateway answers, the response stays 200 and ipfs_match is null.

Every accepted response carries three headers.

A refusal returns 429, with these three headers and Retry-After. On this endpoint, Retry-After is the duration of the window, that is 60 seconds.

#Path and query parameters

This endpoint has no query parameter.

identifier accepts three forms, tried in this order.

The server recognizes the item hash without distinction of case. It recognizes the serial number the same way, and it brings the characters that look alike back to a single form before searching: an I or an L that you type by hand finds the 1 again, an O finds the 0.

This endpoint does not accept the certificate of authenticity number. You use it on GET /certificate/{identifier}.

#Headers

No header is required.

#Request body

None. This request has no body.

#Example request

Integrity check of the passport of the item whose printed serial number is 0ABCDEFGHJKM. The examples use this form because it fits in 12 characters. A token identifier is written at the same place in the address, on 77 or 78 digits. The three examples set the same timeout of 30 seconds, for the reason given above.

curl -i --max-time 30 https://api.sealtrust.io/v1/passport/0ABCDEFGHJKM/verify

const reponse = await fetch(
  "https://api.sealtrust.io/v1/passport/0ABCDEFGHJKM/verify",
  { signal: AbortSignal.timeout(30000) },
);

if (reponse.status === 404) {
  console.log("Aucun passeport public à contrôler pour cet article.");
} else if (reponse.ok) {
  const controle = await reponse.json();
  console.log(controle.db_hash_match);
  console.log(controle.ipfs_match, controle.ipfs_uri);
  console.log(controle.seal.sealed, controle.seal.chain_link_match);
} else {
  console.log(reponse.status, await reponse.json());
}

import requests

response = requests.get(
    "https://api.sealtrust.io/v1/passport/0ABCDEFGHJKM/verify",
    timeout=30,
)

if response.status_code == 404:
    print("Aucun passeport public à contrôler pour cet article.")
elif response.ok:
    controle = response.json()
    print(controle["db_hash_match"])
    print(controle["ipfs_match"], controle["ipfs_uri"])
    print(controle["seal"]["sealed"], controle["seal"]["chain_link_match"])
else:
    print(response.status_code, response.json())

#Example response

HTTP code 200.

{
  "db_hash_match": true,
  "ipfs_match": true,
  "ipfs_uri": "ipfs://bafybeiaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
  "ipfs_gateway_url": "https://passerelle.exemple.invalid/ipfs/bafybeiaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
  "data_hash": "1111111111111111111111111111111111111111111111111111111111111111",
  "computed_hash": "1111111111111111111111111111111111111111111111111111111111111111",
  "passport_version": 3,
  "seal": {
    "sealed": true,
    "sealed_at": "2026-05-14T09:12:44+00:00",
    "algorithm": "st-dpp-chain-v1",
    "version_hash": "2222222222222222222222222222222222222222222222222222222222222222",
    "prev_version_hash": "3333333333333333333333333333333333333333333333333333333333333333",
    "linked": true,
    "chain_link_match": true
  }
}

The response has eight fields and nothing else.

#Which passport the server checks

The check covers the latest published version whose visibility is public. The server first looks for the passport specific to the item. Failing that, it checks the passport of the model, shared by all the items of the model.

The response does not say which of the two scopes answered. Both number their versions separately, so passport_version can be 1 in either case.

The server never checks here a passport reserved to the owner or a passport reserved to the brand. The response is then 404, as if no passport were published.

#When the server returns the ipfs_uri address to you

You receive the address of the public copy when its content is exactly the public passport the brand publishes today. Otherwise, ipfs_uri and ipfs_gateway_url are null.

A brand that changes its access rules changes what its public passport shows. A copy posted before that change is therefore no longer announced until the brand has posted a new one. Never read these two null values as a verdict on the copy.

ipfs_match at null says nothing about the integrity of the copy. Try again later before concluding.

#The seal block

The seal block therefore takes three forms, and you must be able to tell them apart without deducing anything from a missing field.

{ "sealed": false }

{
  "sealed": true,
  "sealed_at": "2025-11-02T08:30:00+00:00",
  "algorithm": "st-dpp-chain-v1",
  "version_hash": null,
  "prev_version_hash": null,
  "linked": false,
  "reason": "sealed_before_chain"
}

{
  "sealed": true,
  "sealed_at": "2026-05-14T09:12:44+00:00",
  "algorithm": "st-dpp-chain-v1",
  "version_hash": "2222222222222222222222222222222222222222222222222222222222222222",
  "prev_version_hash": "3333333333333333333333333333333333333333333333333333333333333333",
  "linked": true,
  "chain_link_match": true
}

#Which verdict to read first

chain_link_match at false is the signal that a sealed version was modified after its publication. It is the strongest verdict in this response. It comes from a recomputation made at the moment of your call.

ipfs_match at false carries the same kind of signal about the public copy.

#Errors

The body of an error response carries a detail field.

An unreachable gateway does not produce an HTTP error. The response stays 200 and ipfs_match is null.

#See also

• GET /passport/{identifier}/proof, gather the public proofs of the passport of an item.
• GET /passport/{identifier}, read the published passport of an item.
• GET /certificate/{identifier}, read the certificate of authenticity of an item.
• Trust and proofs, what each proof establishes and how a third party redoes the verification.