Inspectors do not
browse websites.
The realistic path is identifier, then lookup, then a call for structured data. The web page is for people.
How a system actually arrives.
Read now, or read as of a date.
Current state
The passport as it stands, filtered to what the caller is entitled to see.
Historical state
The version in force on a given date, straight from the archive.
Batch or item
Both identifier levels are accepted, so per-unit granularity changes what comes back, not how you call.
This contract is published separately from the interfaces our own console uses. Internal endpoints change when the product changes; a contract other people build against does not get to move.
Write operations are reserved rather than missing — they answer as "not implemented", so an integrator knows the path is right and the capability is not open yet.
Where we said no on purpose.
The scan address does not serve data to machines. Scanning has consequences: counters advance, the previous link expires, a record is written.
Pulling data should never consume somebody's scan, or leave a genuine product looking used.
The identifier we publish is fixed at issue. It is never derived from how a request happened to reach us. An identifier that changes with the hostname is worthless the moment it is registered somewhere else.
Nobody submits by machine yet.
The EU registry accepts a web form and file uploads. There is no machine submission path, for anyone — so a vendor promising an automated registry connector today is describing a road that has not been built.
What we do instead: prepare a validated submission file from your passports, with every record checked locally first, because a single bad row rejects an entire upload. The operator submits it, and we record the result against the passport.
When a machine path appears, it slots into the same place. Nothing about your data changes.