Included free · One identity, many places · ECZ-ID API

Bindings

Every place your API appears, tied to one identity.

A binding records a public place where your API already appears — your published API documentation or an OpenAPI description you host — against its one ECZ-ID. Where a live proof method reaches the place, completing the proof shows the binding as verified, with when it was last verified. Adding a binding never creates a second identity.

Get a FREE API Passport Verify an ECZ-ID All API products

Type: Included free
Price: £0 — included with every free Passport
Acquired and paid in: TrustOps
Operated in · proved by: Dashboard · Resolver

The problem

Why it matters.

The same API shows up in several places under several accounts. Readers cannot tell that they are the same thing, or who stands behind each one.

Built for

API providers with versioned base URLs, regional endpoints or more than one gateway.
Teams that move, rename or re-platform an API without changing what it is.
Reviewers who need to know that two endpoints are one API.

What changes

One identity across every place it appears.
Every bound place pointing back to the same public record.
A clear record of where each binding was learned, which are verified, and as of when.

What you receive

Concrete deliverables, not a vague trust score.

Basic bindings with every free Passport.
The source each binding was learned from.
The live proof methods for API Passports: OpenAPI info.x-ecz-id, Domain /.well-known file or DNS TXT record.
Bindings shown on the public record, with consent.

Bindings on one record

Identity: ECZ-XX-XXXXXX::API_PASSPORT-XXXXXX
Verified binding: your published API documentation
Proof method: Domain /.well-known file or DNS TXT record — whichever was completed
Last verified: YYYY-MM-DD
Re-check due: YYYY-MM-DD
Declared binding: an API marketplace or gateway listing — connector Planned; no Last verified date
Learned from: The source of each binding, recorded

Illustrative structure with placeholder values. A declared binding shows no Last verified date; a verified one shows when it was last verified and when a re-check is due.

How it works

A short path from need to something usable.

Passport — Your API holds one free API Passport, issued through TrustOps and written by ECZ-ID Core.
Bind asset — Name an asset your API is known by — for example your published API documentation. Binding never creates a second identity.
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.
Prepare — Your ECZ-ID console gives you the exact value to publish for that method.
Complete proof — Publish it on the asset you control, then tell ECZ-ID the proof is in place.
Review — The binding is reviewed before anything about it is published as verified.
ECZ-ID verification — ECZ-ID checks the published proof and records the outcome with the time it checked.
Resolver — The public record shows the binding, its proof method, when it was last verified and when a re-check is due.
Operate — 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.

How it relates to your Passport

Bindings are part of the free Passport. AEC counts the entities you actively manage with live bindings; PulseGuard can evaluate the current state of bound surfaces; ECZ-ID Watch tells followers when they change.

Use cases

Moving from /v1 to /v2 without minting a new identity: the new base URL is recorded against the same API.
Binding the OpenAPI description you host through OpenAPI info.x-ecz-id, so a reader who has the document can reach the record.
Binding your published API documentation through a Domain /.well-known file or a DNS TXT record.
Recording an API marketplace or gateway entry against the same API rather than as a second identity.

Price

Included free, with every Passport.

£0. It is part of the free API Passport — permanent, not a trial, and no card is required.

After you take it

TrustOps acquires
Take the free Passport in TrustOps; your organisation's ECZ-ID Business Passport — Declared — FREE is reused or created.
Dashboard operates
Operate it in the Dashboard: publish, bind and copy your proof links.
Resolver proves
Anyone resolves the current record on the Resolver.

Privacy, security and evidence

What is collected, published and kept.

Each binding records where it was learned.
A verified binding shows its proof method and when it was last verified; a declared one is shown as declared.
Publication of bindings follows the same consent as the record.

Boundaries

The claims stop here.

Passport ≠ Binding. A binding records an asset; it is never a second identity.
Binding ≠ Authority. A binding does not grant, prove or imply authority to act.
Binding ≠ Certification. A completed proof shows control of the named asset when it was checked. It is not a certification, does not grant authority, and says nothing about safety or quality.
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.
A place no live proof method reaches yet can be recorded as a declared binding. The connector that would verify it is marked Planned; until it ships, that binding is shown as declared, never as verified.

Integrations and questions

Works with what you already run.

Your published API documentation — Domain /.well-known file or DNS TXT record.
An OpenAPI description you host — OpenAPI info.x-ecz-id.
An API marketplace or gateway listing — recorded as a declared binding; its connector is Planned.
The repository the API is built from — recorded as a declared binding; its connector is Planned.

Does each version, environment or gateway need its own Passport?: No. Versions, environments, base URLs and gateways of that API are not separate Passports.
Does a binding prove we control the domain?: 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 today; the connector for it is Planned.
Does a binding change how my API authenticates callers?: No. Authentication and authorisation stay with OAuth, your IAM and your gateway. A binding is a public statement about identity, outside the call path.
Which places can a live proof method reach today?: Your published API documentation — Domain /.well-known file or DNS TXT record. An OpenAPI description you host — OpenAPI info.x-ecz-id. An API marketplace or gateway listing — recorded as a declared binding; its connector is Planned. The repository the API is built from — recorded as a declared binding; its connector is Planned. A place no live proof method reaches yet can be recorded as a declared binding. The connector that would verify it is marked Planned; until it ships, that binding is shown as declared, never as verified.

Start with a free API Passport.

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

Get a FREE API Passport Verify an ECZ-ID