Developer Onboarding
This site is your discovery and build gateway. TrustOps is where you acquire credentials. Resolver is where you prove identity. Here's how the complete journey works.
Starting your build?
Browse the Agent Directory to find your archetype, pick a starter kit, and identify which TrustOps package you need. When you hit the credentialing midpoint, go to TrustOps.Returning after TrustOps?
Paste your Agent ECZ-ID and API keys into your kit's config file. Wire the identity hooks. Test locally. Verify through Resolver. Then deploy.What you do first
- 1Choose a starter kit or archetype
- 2Install dependencies (Python 3.10+ / Node 18+)
- 3Go to TrustOps /start — acquire credentials
- 4Return and paste credentials into config
- 5Run locally, verify via Resolver, deploy
What comes back from TrustOps
- Agent ECZ-ID(s) — your permanent identity anchor
- Credential manifest — JSON with declared capability metadata
- API keys (issued in TrustOps) — for identity injection & hooks
- Resolver-verifiable status baseline — confirmed through Resolver, not asserted by this site
Where to paste it
Each starter kit specifies exactly where credentials go. Typically: .env or a manifest.json config. The ECZ-ID agent context is injected automatically from there at runtime.
What success looks like
Resolver returns a resolver-verifiable state for your Agent ECZ-ID. Any external party can query it without an account.
Check via Resolver ↗Three Surfaces, One Journey
ECZ-ID operates across three distinct surfaces. Understanding where each responsibility lives is the key to a smooth developer experience.
Developer Gateway
You Are Here
This is your discovery and build surface. Explore agent archetypes, browse starter kits, follow guided build flows, and understand the complete ECZ-ID domain map. This is where you start and where you return after credentialing.
- Discover agent patterns and starter kits
- Follow guided build flows
- Identify required trust objects
- Complete integration after credentialing
TrustOps
Credentialing Checkpoint
TrustOps is the commercial and operational control surface. This is where you acquire your ECZ-ID passports, agent credentials, API keys, and production configurations. All credentialing, sales, and credential lifecycle management happens through TrustOps.
- Acquire ECZ-ID Business Passport
- Provision Agent Credentials
- Receive API keys and manifests
- Manage credential lifecycle
Resolver
Verification Surface
Resolver is the public verification surface. Any party can verify any ECZ-ID without needing an account. This is where identity claims are proven, resolver state is queried, and provenance chains are traced.
- Verify any ECZ-ID identity
- Query resolver state
- Trace provenance chains
- Public, no account required
Understanding the Complete Identity System
Before you build, understand what the system contains and how the pieces fit together.
ECZ-ID Business Passport™
The parent passport. Root credential for every organisation. All child passports, packages, and derived add-ons attach here.
7 Categories / 33 Child Passports
Digital & Operational, Product, Risk & Transfer, Robotics, Road & Freight Mobility, Aerial Mobility, Infrastructure-Grade, and Control & Trust Overlays.
33 Packages
18 core bundles (includes KYA Ready Pack™) + 8 advanced / accelerator packages (includes ECZ-ID Digital Counterparty Infrastructure Pack™) + 7 extension packages (DORA, SBOM, Trade Finance, Construction). Commercial acquisition objects for activating child passports and enterprise extensions. Plus 9 add-ons / companion products.
ECZ-ID Insurability Readiness™
Derived add-on. NOT a package. Auto-computed from active passport state, evidence state, and canonical Backend/Core rules. Indicates readiness for insurer engagement.
Badges & Public Proof
After verification, entities receive resolver-verifiable badges—public proof URLs that anyone can check without an account.
Deployment
After credentialing and Resolver checks, deploy into your environment. ECZ-ID identity travels with your entity. No vendor lock-in.
Package naming & SKU reference — DORA and SBOM
The public display names changed in the April 2026 naming alignment. The canonical SKU layer — used in TrustOps, API references, and all backend identifiers — is unchanged. Agents and integrations must reference the SKU, not the display name.
DORA Essentials
SKU: ECZ-BUNDLE-DORA-VENDOR
Slug: dora-vendor-pack
Previously named: DORA Vendor Pack. SKU and slug unchanged.
SBOM Essentials
SKU: ECZ-BUNDLE-SBOM-LIABILITY
Slug: sbom-liability-pack
Previously named: SBOM Liability Pack. SKU and slug unchanged.
All TrustOps API calls, flow configurations, and resolver queries continue to use the original SKU and slug identifiers. Do not update integrations based on display name alone.
The Midpoint Credentialing Model
Why credentialing at the midpoint produces better agents than credential-after-build.
Why Not Build First, Credential Later?
Agents built without identity infrastructure require retrofitting. Identity hooks bolted onto finished agents are weaker, harder to maintain, and produce less trustworthy audit trails. The midpoint model ensures identity is woven into the architecture from the start.
Why Not Credential First, Build Later?
Developers need to understand what they're building before they can specify the correct trust objects. The initial build steps clarify the agent's architecture, boundaries, and capabilities—information needed for accurate credentialing.
The Midpoint Is the Sweet Spot
By the midpoint, you understand your agent's needs. You can specify exactly which passports and capabilities are required. The remaining build steps then integrate those real credentials into the agent's architecture, producing a resolver-verifiable, commercially legible agent.
The Complete Journey
What Comes Back from TrustOps
After credentialing in TrustOps, you return with concrete artefacts that integrate into your agent.
Agent ECZ-ID
A unique, resolver-verifiable identity string for each agent. This is the agent's permanent identity anchor.
Credential Manifest
JSON configuration containing declared capability metadata, operational boundaries, and delegation permissions.
API Keys (issued in TrustOps)
ECZ-ID API keys, issued through TrustOps, for identity context injection, verification hooks, and audit trail generation. This site does not issue keys.
Resolver-Verifiable Status
Initial resolver-verifiable status. Confirmed through Resolver, not asserted by this site.
How to Resume and Finish the Build
After acquiring credentials from TrustOps, you return to the Developer Gateway to complete integration.
Inject Your Credentials
Add Agent ECZ-ID, API keys, and credential manifest to your agent configuration. Each starter kit specifies exactly where these go.
Wire Identity Hooks
Connect ECZ-ID identity-context patterns to supported agent actions and integrations.
Test in Sandbox
Run your complete agent in the ECZ-ID sandbox environment. Verify identity flows, check provenance chains, and validate audit trails.
Verify Through Resolver
Use Resolver to verify your agent's identity, check resolver state, and trace provenance chains end-to-end.
Deploy to Production
Deploy your resolver-verifiable agent into your environment after TrustOps and Resolver checks. ECZ-ID identity travels with the agent where supported.
What You Need to Get Started
Prerequisites for the ECZ-ID developer experience.
SDK Capabilities
The ECZ-ID SDK handles identity complexity so you can focus on building.
Need Help?
Developer support is available through TrustOps. Architecture guidance, integration patterns, deployment planning, and custom configurations.
Contact via TrustOps ↗Ready to Start Your Journey?
Choose a starter kit to begin, or credential directly through TrustOps.