Skip to content

SDKs and libraries

Two different things are called an SDK. Only one of them exists yet.

The SDK Passport family is an identity for a library you publish. An ECZ-ID client library is something you would install and call. This page keeps them apart, and says plainly which one you cannot have today.

The integration route that works today needs no library at all.

Disambiguation

Which one did you come here for?

These two meanings share a word and share nothing else. Conflating them is the fastest way to leave with a false belief about what is available.

Meaning 1 — a Passport family

You publish a library, and want it to have an identity

The SDK Passport family gives one logical library or SDK a permanent ECZ-ID, published against the organisation that maintains it. The subject is your library. Consumers of it can resolve who stands behind the thing they are about to depend on.

Free, but the acquisition door is not open on this property yet.

Meaning 2 — a client library

You want a library that talks to ECZ-ID from your code

An ECZ-ID client SDK for developers. There is not one. No package, no install command, no version, and nothing on this site that pretends otherwise.

Not published yet.

Meaning 1 — the Passport family

One SDK Passport is one logical library or SDK across languages and registries.

Same subject law as every other family: one Passport is one logical thing your organisation operates or maintains. What varies between families is only what that thing is.

What one SDK Passport covers

One library, with a permanent identifier and the organisation that maintains it named on the record. Somebody deciding whether to take a dependency can resolve it without an account, and read who is behind it rather than inferring from a registry profile.

Three managed distribution or release channels are included free. A channel you put under management consumes one of those. Identity is free. A Passport is never metered, and issuing one consults no entitlement.

Not a separate Passport

  • Versions and releases

    Every release of the same library carries the same identity. An identifier that changed with the version number would be a version string, not an identity.

  • Registry channels

    The same library published to several package registries is one subject with several distribution channels, not several libraries.

  • Language bindings of the same library

    Bindings that expose one design in several languages stay one Passport. Two genuinely separate products, maintained separately, are two.

  • Mirrors and rebuilds

    A mirror redistributes what you already published. It is a channel, and it does not create a new subject.

The free SDK Passport door is not open here yet

The Agent and MCP families have live acquisition doors on this property. The SDK family does not, so there is no button on this page that would issue you one. When it opens it will be free. Your ECZ-ID does not change. Taking an adjacent identity later never disturbs the one you hold now. Until then, the Developer Gateway is where that family is documented.

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

Adjacent Passports are suggested, never issued for you. If your agent also exposes an MCP server or an API, you choose whether to give those an identity too.

Meaning 2 — the client library

There is no ECZ-ID client SDK. Stated plainly, because the alternative is worse.

A property whose entire argument is that published claims should be checkable cannot publish a package name that resolves to nothing. So it does not.

No package, no install command

There is no name to type, in any registry, for any language. This site names no library, publishes no import snippet and pins no version.

No SDK version and no protocol binding

Nothing here describes an A2A binding, a plugin or a framework adapter shipped by ECZ-ID. Where a technical detail is not published, this site omits it rather than approximating it.

If you find one, it is not ours

An install command for an ECZ-ID client library, from any source, is not something this programme has published. Treat it accordingly.

Status: Planned. Full integration reference, schemas and API documentation live on the Developer Gateway. This property gets you an identity and points you at the right place to wire it in.

What works today

The route that is live needs no library at all.

An agent declares its ECZ-ID at a well-known path on a surface it already serves. It is a static file. No library, no dependency, no change to the agent loop, and nothing new in the execution path.

One file on a surface you already serve

/.well-known/ecz-agent.json

The agent declares its ECZ-ID at a well-known path on the deployment it already exposes. The Publish Kit issued with your Passport gives you the contents; you serve the file the way you serve any other static asset.

ECZ-ID stays outside the execution path. It does not broker your agent's calls, hold its credentials, or sit between it and the systems it uses.

Which makes the language question moot

A static file has no runtime, so there is nothing to port. The route is identical in every language below, and in the ones not listed.

  • TypeScript and JavaScript

    Publish a static JSON file from the deployment you already run.

  • Python

    Publish a static JSON file from the deployment you already run.

  • Go

    Publish a static JSON file from the deployment you already run.

  • .NET

    Publish a static JSON file from the deployment you already run.

One Agent Passport is one logical AI agent operated by your organisation. Publish it once, from the deployment that already exists, and the identity is readable by anyone — including systems that will never run your code.