Skip to main content
Version: v0.25.0 (Latest)

Creating the First Tenant

Tenants are registered through the Platform Admin API on the platform host. These calls carry the operator bearer token obtained through operator sign-in. Schemas are in the Platform Admin API reference.

Register the tenant

Registration creates the tenant with an owner account and runs tenant setup. Setup provisions the tenant authorization server, the tenant-named KMS provider and default keys, the tenant did:web identifier, issuer and verifier instances when requested, and the gateway endpoint bindings for the tenant host. Owner credentials are delivered by email in production; the example below disables delivery:

Register tenant

Endpoint: POST /api/platform/admin/v1/tenants

Captured response: 201 Created

This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.

Live against connected environment

Connect an environment to rewrite this call to real service bases and run it.

The correlation id tracks the setup workflow. A completed workflow means the tenant runtime defaults and gateway bindings are in place:

Get tenant onboarding status

Endpoint: GET /api/platform/admin/v1/tenant-onboarding/00000000-0000-4000-8000-000000000000

Captured response: 200 OK

This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.

Live against connected environment

Connect an environment to rewrite this call to real service bases and run it.

If registration returns 503 SERVICE_UNAVAILABLE and the platform or tenant-AS logs mention REMOTE_PLATFORM_CONFIG_UNAVAILABLE, platform.config.get, or Missing Authorization header, inspect the deployment runtime Secret before retrying. serviceIdentity.internalClientExistingSecret must reference a Secret in the release namespace containing internal-client-secret; platform and tenant-AS must both be restarted after that credential is created or rotated. Also verify keystore.existingSecret and its keystore-password key. This is an east-west service-identity failure, not an operator bearer-token or database migration failure. See Images and Helm chart for the required Secret and container operations for deployment checks.

If the STS response is HTTP 400 invalid_target, diagnose in this order: caller serviceIdentity.clientIds entry, effective route serviceTokenAudience, the caller registration's default-access-token-audience and allowed-access-token-audiences, then the receiver expected audience. An omitted audience requires a nonblank default; one explicit audience must be that default or an allowed additional target. Missing defaults, multiple or duplicate values, and unregistered targets are rejected. Routes declaring serviceTokenAudience or preferServiceTokenOverSessionBearer=true fail closed and do not fall back to the operator/session bearer, delegation, or anonymous access.

Match the response's exact description to the failed rule:

  • Invalid target: No audience was requested and this client has no default access-token audience
  • Invalid target: Client credentials access tokens are restricted to one audience per request
  • Invalid target: Requested audience is not registered for this client

The tenant identifier returned here is used in every tenant-scoped call that follows:

Get tenant

Endpoint: GET /api/platform/admin/v1/tenants/00000000-0000-4000-8000-000000000000

Captured response: 200 OK

This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.

Live against connected environment

Connect an environment to rewrite this call to real service bases and run it.

The list endpoint confirms the tenant is visible to the platform operator:

List tenants

Endpoint: GET /api/platform/admin/v1/tenants

Captured response: 200 OK

This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.

Live against connected environment

Connect an environment to rewrite this call to real service bases and run it.

Gateway endpoint bindings

Tenant setup creates route metadata records for the tenant host. These are gateway bindings, not direct workload URLs. Wallets resolve issuer metadata, authorization-server metadata, verification requests, and DID documents through https://<tenant>.<base-domain>:

List tenant gateway endpoint bindings

Endpoint: GET /api/platform/admin/v1/tenants/00000000-0000-4000-8000-000000000000/public-endpoints

Captured response: 200 OK

This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.

Live against connected environment

Connect an environment to rewrite this call to real service bases and run it.

Runtime service discovery

After tenant onboarding, the collection resolves the browser-safe runtime-config projection for the selected tenant. This returns the tenant-scoped API bases and endpoint paths used by later KMS, DID, issuer, verifier, credential-design, status-list, and DCQL calls. The deployment still exposes tenant services through the tenant host; it does not ask clients to call issuer.<domain> or verifier.<domain> service hosts.

Resolve tenant runtime service discovery

Endpoint: GET /api/platform/bootstrap/v1/runtime-config/admin-console

Captured response: 200 OK

This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.

Live against connected environment

Connect an environment to rewrite this call to real service bases and run it.

The verifier runtime APIs key DCQL bindings by the verifier party id, not by the public instance slug. The collection resolves the platform-created verifier party id before it creates DCQL bindings or OID4VP verification requests:

Resolve verifier party id

Endpoint: GET /api/platform/config/v1/tenants/00000000-0000-4000-8000-000000000000/oid4vp/verifier/instances

Captured response: 200 OK

This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.

Live against connected environment

Connect an environment to rewrite this call to real service bases and run it.

Next, configure sign-in for the tenant.