Skip to content
ECZ-IDAPI
Free Passport: Get a FREE API Passport

Free identity

The free API Passport

One API Passport covers one logical API your organisation operates — not each version, not each environment, and not each gateway in front of it. This page is the whole of what the free identity establishes, and the four things it deliberately does not say.

The subject

One API Passport is one API

One API Passport is one logical API operated by your organisation.

What never becomes a second Passport

Versions, environments, base URLs and gateways of that API are not separate Passports.

The shape of the identifier

ECZ-XX-XXXXXX::API_PASSPORT-XXXXXX

A pattern, not a real record. The identifier of your organisation’s ECZ-ID Business Passport (the Parent) comes first, and the API Passport follows the :: separator.

Why an API needs one

Your API is somebody else's dependency

Customers, partners and agents all decide who they are depending on before they integrate. Today most of them decide from a hostname.

  • Your API is somebody else's dependency

    A customer's product, a partner's integration and an agent's plan all depend on your API. Each has to decide who it is depending on, usually from nothing more than a hostname.

  • Base URLs move; the identity should not

    Versions, regions, environments and gateways change. One ECZ-ID stays with the logical API, and each surface becomes a binding against it rather than a new thing to trust.

  • Machines need a record they can read

    An agent or a procurement tool has no colleague to ask. The Resolver serves the same record as JSON, with no account and no key, and tells software to re-check before reliance.

What the record lets a customer or a machine answer

Which API is this?
One ECZ-ID names the logical API, whatever its base URL or version is today.
Who operates it?
The organisation on the record, through its ECZ-ID Business Passport, with its tier stated plainly.
What real surfaces are bound to it?
Its OpenAPI description, proved through OpenAPI info.x-ecz-id, and the domains its documentation and endpoints answer on, proved through a Domain /.well-known file or a DNS TXT record — each verified binding with its proof method and Last verified time. A marketplace or gateway listing, or the repository, is recorded as a declared binding.
What public state is current?
The lifecycle state as last read, with the time it was read.
Where can it be re-checked?
On the Resolver, by page or JSON, by anyone, with no account.
What changed over time?
Where Watch and LedgerCore are in use: what changed, when, and the evidence that was recorded.

ECZ-ID does not replace API authentication, OAuth, IAM, authorisation or your API gateway. It sits outside the call path and publishes which API it is and who operates it — to readers who have access to none of those.

Included

What the free Passport establishes

£0 · No card required · Permanent, not a trial.
  • A persistent ECZ-ID for the API.
  • Your organisation on the record as its operator. Its ECZ-ID Business Passport — Declared — FREE is created if you do not already have one.
  • A public Resolver record anyone can open, and the same record as machine-readable JSON.
  • A badge, a QR code and a share link.
  • Basic bindings to the public places where your API already appears.
  • Lifecycle and current public state, evaluated on demand.
  • Claim and recovery.
  • Basic participation in the Digital Entity Graph.
  • Essential lifecycle evidence, kept in LedgerCore.

Publishing the record is your decision. Nothing becomes public until you consent, and you can withdraw publication later.

Everything included free

Each free capability, in full

Every part of the free Passport that stands on its own has its own page: what it does, what it looks like, and where its claims stop.

The flow

How to get one

6 steps, from taking the Passport to re-checking before reliance: you bind an asset and publish its proof, it is reviewed, ECZ-ID verification checks it, and the Resolver shows the result to anyone.

  1. Take the Passport

    Start in TrustOps with one sign-in. Your organisation's ECZ-ID Business Passport — Declared — FREE is reused or created, and your API gets its free API Passport — one ECZ-ID that does not change.

  2. Bind an asset

    Name an asset your API is known by — for example your published API documentation. Binding never creates a second identity. Each binding records where it was learned.

  3. Choose and prepare a proof method

    Choose the live proof method that fits the asset: OpenAPI info.x-ecz-id, Domain /.well-known file or DNS TXT record. Places no live method reaches are marked Planned. Your ECZ-ID console gives you the exact value to publish for that method.

  4. Complete the proof and review

    Publish it on the asset you control, then tell ECZ-ID the proof is in place. The binding is reviewed before anything about it is published as verified.

  5. ECZ-ID verification, then the Resolver

    ECZ-ID checks the published proof and records the outcome with the time it checked. The Resolver then shows the binding with its proof method, its Last verified date and its Re-check due date — to anyone, with no account and no API key.

  6. Operate — re-check before reliance

    Keep the proof in place. A binding is verified as of a time, not indefinitely: ECZ-ID does not renew a bound binding, and after its method's freshness window a new binding is the fresh proof — re-check before reliance. Publish the ECZ-ID where people and machines already look. Strengthen only if it is useful: Parent verification, monitoring, evidence and authority are optional, and none is needed to hold a Passport.

The boundary

What the Passport deliberately does not say

These four distinctions are the whole reason the record is worth reading. A page may shorten its own copy; it may not weaken these.

  • DECLARED ≠ VERIFIED

    A DECLARED record states what your organisation says about itself, with the date it said it. It is not the outcome of an independent check.

  • Passport ≠ Binding

    The Passport identifies the API. A binding records a public place where it already appears. Adding a binding never creates a second identity.

  • Binding ≠ Authority

    A binding shows that a relationship has been declared. It does not grant, prove or imply authority to act.

  • Parent verification ≠ API verification

    A VERIFIED or ASSURED Parent verifies your organisation. It does not verify the API.

An ECZ-ID does not make anything safe, certified, approved or compliant, and holding one does not make you compliant with anything.

The Resolver is public, read-only proof of what is currently declared and verified, with the time it was read. A record is not a verdict, and the record itself says so and asks to be re-checked. Re-check before reliance.

Get a FREE API Passport

Where next

Keep going with ECZ-ID API.

Get a FREE API Passport