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

ECZ-ID API Passport™

Give your API an identity customers and machines can independently check.

For organisations that publish, sell or operate APIs. Connect the organisation operating the API, its real endpoint and domain bindings and its current public proof through one enduring ECZ-ID — so a customer, a partner or an agent can see which API this is and who answers for it, and re-check it before relying on it.

Get a FREE API PassportVerify an ECZ-IDBuild and integrate(opens in a new tab — developers.ecocitizenz.com)

£0 · No card required · Permanent, not a trial.

Everything included with one FREE API Passport

Identity
ECZ-XX-XXXXXX::API_PASSPORT-XXXXXX
Operator
Your organisation's ECZ-ID Business Passport — Declared — FREE, created if you do not have one
Public proof
Resolver page + machine-readable JSON, open to anyone
Share
Live website badge + QR code + share link
Connections
Basic bindings + Digital Entity Graph participation
Operate
Lifecycle/current state on demand + claim/recovery + essential LedgerCore evidence
Price
£0 — no card required — permanent, not a trial

The website badge is the same live-proof pattern EcoCitizenz uses in every site footer: click it to reach current Resolver proof. DECLARED information is self-declared; re-check the live record before relying on it.

Free API Passport

What your free API Passport establishes.

One API Passport is one logical API operated by your organisation. Versions, environments, base URLs and gateways of that API are not separate Passports.

Free · Permanent · No card

The ECZ-ID launch model

Every organisation starts with one ECZ-ID Business Passport — Declared — FREE. Each of the seven family Passports — Agent, MCP, Plugin, API, IoT, SDK and Service & Workload — is free, and is taken in TrustOps once TrustOps publishes that family's door as open.

ECZ-ID Business Passport — Declared — FREEParent · created with your first family Passport

Other free starts

  • Free WatchFollow up to three ECZ-IDs on this device and see what changed, with no account and no email.Use Free Watch
  • Free Trust CheckCheck a public URL: we read its public signals and match them to the free Passport families by fixed rules. Advisory; nothing is created.Run the free check

Included, at £0

  • 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. About the Parent
  • A public Resolver record anyone can open, and the same record as machine-readable JSON. About the Resolver
  • A badge, a QR code and a share link. About badges and QR
  • Basic bindings to the public places where your API already appears. About bindings
  • Lifecycle and current public state, evaluated on demand. About PulseGuard
  • Claim and recovery.
  • Basic participation in the Digital Entity Graph. About the Graph
  • Essential lifecycle evidence, kept in LedgerCore. About LedgerCore
  • Publish Kit for your OpenAPI description.
  • Manage from your ECZ-ID account.

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

One API, one Passport

For example, your payments API keeps one Passport across its versions, environments and gateways.

A new version, environment, regional alias or gateway is not a new Passport.

What the record never blurs

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.
Get a FREE API PassportRead everything included

Why, and how it works

From Passport to verified binding.

Why your API needs an ECZ-ID, and exactly what happens between taking the Passport and relying on a verified binding.

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

Base URLs change. The API's identity does not.

  1. Endpoints and domains

    api.example.com, a regional endpoint, a partner-facing hostname: the real surfaces a caller meets, each recorded against the API as a binding.

    Underneath · replaceable

  2. Versions, environments and gateways

    /v1 to /v2, staging to production, the gateway in front: history and routing under the same API, never a new identity.

    Underneath · replaceable

  3. binds to

    API Passport

    One ECZ-ID for the logical API — what a customer means by “your payments API” — across every base URL it answers on.

    Enduring · public · accountable

  4. operated by

    Operator

    Your organisation's ECZ-ID Business Passport — Declared — FREE, strengthened to VERIFIED or ASSURED only if you choose.

    Enduring · public · accountable

An OpenAPI description you host is bound through OpenAPI info.x-ecz-id, and your published API documentation through a Domain /.well-known file or a DNS TXT record on a domain you control. An API marketplace or gateway listing is recorded as a declared binding; its connector is Planned.

What a customer or a machine can answer from the record

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.

  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 binding law

  1. Passport
  2. Bind asset
  3. Proof method
  4. Prepare
  5. Complete proof
  6. Review
  7. ECZ-ID verification
  8. Resolver
  9. Operate

A binding is verified as of its Last verified time, and the record shows its Freshness. ECZ-ID does not renew a bound binding: once its proof method's freshness window has passed, the result is history and a new binding is the fresh proof. Re-check before reliance.

Use cases

What API teams use ECZ-ID for.

Real situations, each served by one product of the ECZ-ID API domain. Every product starts from the same free API Passport; none of them changes what it proves.

Operate this Passport

Operate your API estate.

When one free API Passport becomes many, these are the products TrustOps lists for the API family. Each is optional and separate, and none changes what a Passport proves.

Universal platform

Five universal capabilities. One job each.

Scale → Monitor → Evidence → Understand relationships → Know when something changes.Five ECZ-ID capabilities sit behind every Passport family. All are optional, none changes what a Passport proves, and each is arranged through TrustOps.

One AEC: An API you actively manage in production, with live bindings and current state. A free Passport exists and resolves whether or not you use any AEC.

IoT devices are counted separately, in IoT Fleet Capacity, and never consume AEC.

Authority & evidence, your estate plan and expert help

What a Passport may do and how a proposed action is evaluated, where receipts are kept, how the estate is operated and who can help — each optional, none of them changing what a Passport proves.

Prices and what can be bought today come from TrustOps, which owns every purchase, entitlement and renewal.

Parent assurance

Strengthen the organisation, not the identity.

Every API Passport hangs from your organisation's Parent, the ECZ-ID Business Passport. DECLARED is free and enough to start; VERIFIED and ASSURED strengthen confidence in who is answering for your API — never the API itself.

  1. DECLARED

    ECZ-ID Business Passport — Declared — FREE

    Free · created with your first Passport

    Self-declared organisation identity, published with the date it was declared. Not independently verified.

    Suits: Holding every free Passport in every family, publishing records, adding bindings and being resolved by anyone.

    Never presented as verified.

  2. VERIFIED

    ECZ-ID Business Passport — Verified

    Optional · arranged through TrustOps

    Independent verification of the organisation behind your Passports. Paying opens ECZ-ID's checks; the record shows VERIFIED only after they pass.

    Suits: Production use, and reviewers who need to know who is answering for what they approve.

    Never verifies a child Passport's subject, and never changes an ECZ-ID.

  3. ASSURED

    ECZ-ID Business Passport — Assured

    Optional · arranged through TrustOps

    The higher-assurance organisation posture. Paying opens ECZ-ID's checks; the record shows ASSURED only after they pass.

    Suits: Larger or more sensitive estates, and enterprise procurement.

    Never verifies a child Passport's subject, and never changes an ECZ-ID.

Compare the Parent tiersConfigure in TrustOps(opens in a new tab — trustops.ecocitizenz.com)

Solutions

Solve the review, procurement and supply-chain problem above the identity.

Each solution uses the same free API identity foundation. None is a certification, a score or an approval.

Where it applies — SBOM & software-composition evidence. Connect composition, provenance and release evidence to an enduring digital-product identity. An SBOM describes composition; it is not a declaration that software is secure.

SBOM details

Prices and what can be bought today come from TrustOps, which owns every purchase, entitlement and renewal. All solutions

Flagship digital product

ECZ-ID API Enterprise Security Review & Customer Assurance Kit

Turn API ownership, control and security evidence into an enterprise-review pack.

Before an enterprise integrates an API, its security and procurement teams ask the same things: who operates it, which surfaces are in scope, how callers authenticate, how changes are controlled, what evidence exists and what the provider will not do. Providers answer from scratch for every customer, in a different spreadsheet each time, and deals wait on it.

What you receive

  • API identity and ownership evidence
  • Security-control review prompts
  • Operational and change evidence
  • Customer assurance pack

Boundary: The kit organises review evidence; it is not a penetration test or security certification. Control descriptions are yours. The kit does not test, scan or attest your API's security.

See the full productConfigure in TrustOps(opens in a new tab — trustops.ecocitizenz.com)
The customer assurance pack
Operator
Organisation, Business Passport tier and the API's ECZ-ID
Scope
The bound OpenAPI description, base URLs and environments
Access
How callers authenticate and are authorised — as you describe it
Change
Versioning, change control and incident contact
Evidence
Supporting evidence, with LedgerCore receipts where held
Gaps
Open questions an API reviewer will raise, stated plainly

Illustrative structure. The pack is assembled from the evidence you hold about the API; the Resolver remains the live proof.

Relevant bundles

When the problem spans more than one kind of entity.

Bundles connect the specialist products across a real workflow. Each identity stays distinct; a bundle never merges them.

How the estate fits together

TrustOps acquires. Dashboard operates. Resolver proves.

ECZ-ID Core writes the canonical identity, state and evidence. This website explains and hands off; it never issues, edits or stores an identity.

  1. TrustOps acquires

    Owns acquisition, payment and entitlement. Every free door and every purchase happens there, and nowhere else.

    Open TrustOps(opens in a new tab — trustops.ecocitizenz.com)About TrustOps

  2. Dashboard operates

    The signed-in estate console where you manage Passports, bindings, capacity and the capabilities you hold.

    Sign in — manage from your ECZ-ID account(opens in a new tab — trustops.ecocitizenz.com)About Dashboard

  3. Resolver proves

    Public, read-only proof. Anyone can open the current record and its JSON with no account, and re-check it before relying on it.

    Verify an ECZ-IDAbout Resolver

Developer Gateway documents and integrates. Schemas, client guidance and install routes for resolving ECZ-IDs from your own code.

Open the Developer Gateway(opens in a new tab — developers.ecocitizenz.com)

Live proof

Don't take our word for it. Resolve us.

EcoCitizenz Ltd runs this site and holds its own ECZ-ID. Everything below is read from the public record, by anyone, with no account and no key — including the parts that are empty.

ECZ-ID

active

EcoCitizenz

ECZ-GB-RBS1NW

Operated by
ECOCITIZENZ LTD
Organisation tier
VERIFIED
Bound representations
None published
Public relationships
None published

The parent organisation's identity is verified. This machine is not.

Evidence available

  • Not revoked
  • Anchor recorded · not publicly retrievable
  • No live PulseGuard monitor
  • No receipts in 30 days
Resolve(opens in a new tab — resolver.ecocitizenz.org)JSON(opens in a new tab — api.ecocitizenz.com)View Graph
Last read from the public record 2026-10-14. The Resolver is the authority. Re-check before reliance.

Check it yourself

The same record answers for humans and machines. One is a page, the other is JSON with no authentication in front of it.

curl -s https://api.ecocitizenz.com/api/p/ECZ-GB-RBS1NW.json | jq .

What each field means is documented on the Developer Gateway: Resolver projection(opens in a new tab — developers.ecocitizenz.com)

What it does not prove

That this company is safe to deal with, that its software is correct, or that anyone has audited it. A record establishes who an entity is and who operates it. Everything else is your decision, and you should re-check before you rely on it.

Open the record(opens in a new tab — resolver.ecocitizenz.org)Resolve any ECZ-IDGet the same badge for your organisation

Interoperability

Works alongside what you already run.

An API Passport complements how your API is described, protected and published. OpenAPI describes it, OAuth and your IAM decide who may call it, and your gateway routes and meters it; the Passport publishes which API it is and who operates it. It never replaces authentication, OAuth, IAM, authorisation or an API gateway.

Native where you operate. ECZ-ID where you interoperate.Keep the identities your platforms need. Add the identity everyone else can resolve.

Related family Passports

  • OpenAPI

    What it does: Describes an HTTP API's operations and schemas.

    What ECZ-ID adds beside it: A stable identity for the API the description belongs to, across versions and base URLs.

  • OAuth 2.x and OpenID Connect

    What it does: Delegate authorisation and authenticate a principal for a session.

    What ECZ-ID adds beside it: A durable public record of the subject and its operator that outlives any token and needs none to read.

  • API gateways and API marketplaces

    What it does: Route, meter and publish access to your API.

    What ECZ-ID adds beside it: One identity for the API behind every gateway and listing it appears in.

  • Model Context Protocol (MCP)

    What it does: Connects AI applications to tools and data through a defined client–server protocol.

    What ECZ-ID adds beside it: A resolvable identity for the agent and, separately, for each MCP server it uses — each with a named operator.

Platforms, standards and providers are named to show where ECZ-ID sits alongside them. Naming them implies no endorsement by, or partnership with, their owners.

ECZ-ID complements your frameworks, protocols, OAuth, cloud IAM and workload identity. It replaces none of them and stays outside the execution path.

Read the interoperability boundaries in full

In the OpenAPI description you already publish

OpenAPI info.x-ecz-id is the API family’s own live proof method, beside a Domain /.well-known file and a DNS TXT record for the domains it answers on: put the API’s ECZ-ID at info.x-ecz-id in the OpenAPI description you publish, bind that description to the Passport, and ECZ-ID verification checks it. The Resolver then shows when it was last verified and when a re-check is due.

Nothing about the API’s behaviour changes, and your OAuth, IAM and gateway configuration stay exactly as they are. The Developer Gateway documents the field.

The API surface, described and boundOpenAPI x-ecz-id reference on the Developer Gateway(opens in a new tab — developers.ecocitizenz.com)

Enterprise and questions

Larger estates, and the questions people ask first.

Enterprise, partners and expert help

Estate-wide capacity, procurement terms, partner arrangements and fixed-scope expert engagements are agreed directly rather than bought online. The API Passport itself stays free at any scale.

EnterpriseTalk to us
What does a free API Passport cost?
£0. It is permanent, not a trial, and no card is required. You pay only if you later add scale, assurance or specialist products.
What does one API Passport identify?
One API Passport is one logical API operated by your organisation. Versions, environments, base URLs and gateways of that API are not separate Passports.
Who can check the record for my API?
Anyone. Once you consent to publication, the Resolver serves the record as a page and as JSON, with no account and no key.
What would I ever pay for?
Capacity to operate more entities (AEC), a stronger organisation tier (Parent VERIFIED or ASSURED), monitoring, evidence, relationship intelligence, change awareness, business solutions and specialist digital products. All are optional.
Does the API Passport verify the API?
A DECLARED record states what your organisation says. A VERIFIED or ASSURED Parent verifies your organisation, not the API. A binding completed through a live proof method shows control of the bound asset as of when it was last verified; it certifies nothing about the API itself.

Every question, answered

Start with the identity. Everything else is optional.

£0 · No card required · Permanent, not a trial.

Get a FREE API PassportVerify an ECZ-ID