Works alongside
What an ECZ-ID API Passport sits beside
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.
Adjacent systems
What each already does, and what the Passport adds
OpenAPI
- What it does
- Describes an HTTP API's operations and schemas.
- What an ECZ-ID adds
- 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 an ECZ-ID adds
- 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 an ECZ-ID adds
- 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 an ECZ-ID adds
- 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.
Adjacent identities
The Passports that surround this one
ECZ-ID SDK Passport™
Client SDKs wrap your API. Each SDK is a separate published subject that can name the same operator.
ECZ-ID Service & Workload Passport™
APIs are served by workloads. The service behind an API is a different enduring subject from the API it serves.
ECZ-ID Agent Passport™
Agents are becoming an API's most frequent callers, and each calling agent can present its own identity.
Integrations
Where an API Passport plugs into what you already publish
Your OpenAPI description
Publish the API's ECZ-ID as OpenAPI info.x-ecz-id — info.x-ecz-id in the OpenAPI description you publish — and bind the description to the Passport. It is the API family's own live proof method, beside a Domain /.well-known file and a DNS TXT record, and nothing about the API's behaviour changes.
Base URLs, domains and gateways
Record base URLs, regional endpoints and your published API documentation against one identity, never as second identities. Only a binding completed through a live proof method shows control of that asset, and only as of its Last verified time. A declared binding records the relationship and where it was learned. Neither grants authority. An API marketplace or gateway listing is recorded as a declared binding; its connector is Planned.
Your developer portal and API reference
Place the live badge, QR or share link where developers already meet the API. Each routes to the current Resolver record — not a certification mark.
Agents, procurement tools and CI
Software resolves the same record as JSON with no account or key, and reads the guard fields that tell it to re-check before relying on it.
A live machine record to try: https://api.ecocitizenz.com/api/p/ECZ-GB-RBS1NW.json (opens in a new tab) — EcoCitizenz Ltd’s own Business Passport, resolved with no account and no key. Schemas and client guidance are on the Developer Gateway (opens in a new tab).
Where next
Keep going with ECZ-ID API.
- ProductsEvery API product and service, each with its own page.Open
- The free API PassportWhat it establishes, what it never says, and how it is issued.Open
- Verify an ECZ-IDRead a live record on the public Resolver — no account, no key.Open
- Build and integrateAPI binding on the Developer Gateway.Open (opens in a new tab — developers.ecocitizenz.com)
