Postman Collection and Environment

The customer developer journey is available as a Postman collection. It ships in the deployment repository under postman/ and covers what developers usually do with an EDK Enterprise installation: pick or create a tenant, create a service client for their application, and then call the tenant APIs to manage keys, issue and verify credentials, and publish status and trust information. License installation and first-run setup have to be complete before you start.

The same files are available here for direct download:

• EDK-Enterprise-Deployment.postman_collection.json
• EDK-Enterprise-Deployment.customer.postman_environment.json

For focused protocol work, start with the enterprise integration scenarios. It links the sanitized request/response captures used by the guides for external KMS keys and certificates, Azure Key Vault provider configuration, SD-JWT VC and mDoc issuance, DCQL, OID4VP, and status transitions.

The deployed Developer Console exposes the same mounted OpenAPI operations and can download a policy-filtered, secret-free collection:

• Sphereon Developer Console collection
• Sphereon Developer Console environment

The generated Developer Console collection is a route-safe execution skeleton. For an operation with an upstream request body, use the mounted spec in the console (GET /api/developer-console/v1/specs/{specId}) or the OpenAPI reference linked from the guide to see the actual schema and examples. The BFF request itself carries only the server-approved routeId; it must not be populated with an arbitrary upstream URL, audience, scope, or credential.

Using the collection

1. Import both files into Postman and select the environment. Keep a separate copy of the environment per installation or tenant.
2. Confirm the license and first-run platform setup are complete.
3. Set baseDomain and tenantSlug. Everything else is derived from these two values: the platform is at https://platform.<baseDomain>, the tenant at https://<tenantSlug>.<baseDomain>, and the tenant's authorization server at https://<tenantSlug>.<baseDomain>/as/<tenantSlug>.
4. Work through the three top-level folders. Each one has its own OAuth2 configuration: open the folder, go to Authorization, choose Get New Access Token, then Use Token. Postman keeps the token with the folder and every request in it uses it. Tokens last an hour; get a new one when requests start returning 401.

Folder	Sign in as	What you do
1. Platform operator	Platform operator (authorization code with PKCE)	Tenants: list tenants and register tenantSlug when it does not exist yet. Child tenants (optional) and Share an Azure Key Vault with tenants (optional). You need this folder only to see or create tenants.
2. Tenant owner: create a service client	Tenant owner (authorization code with PKCE)	Find the tenant's default authorization server, list its clients, create the service client serviceClientId, or replace its secret. Skip it if you created the service client in the admin console.
3. Tenant APIs	Service client (client credentials)	Authorization server, Keys and DIDs, Azure Key Vault (optional), Credential issuer, Credential designs, Status lists, Define your own credential, Issue credentials, Verify credentials, Trust domains, Keycloak wallet login (optional).

Each folder starts by listing what exists. The list requests store the ids that later requests need, and create requests skip themselves when the object already exists, so you can run a folder again. Start a folder at its first request. Postman's console (View > Show Postman Console) shows what each request found or skipped. Several folder descriptions link back to the guide that explains them.

Do not run the whole collection in one go with the collection runner: the three top-level folders need three different sign-ins, and the optional folders skip themselves until you set their inputs.

Variable	Meaning
baseDomain	Customer-controlled base domain. The gateway must terminate TLS for platform.<baseDomain> and *.<baseDomain>. Add :port only if the gateway listens on a non-standard port.
tenantSlug	The tenant you work with. The tenant gateway host is <tenantSlug>.<baseDomain>. Switching it clears the ids captured for the previous tenant.
tenantName	Display name, used only when you register the tenant.
serviceClientId, serviceClientSecret	The service client your application uses for the tenant APIs. The server never returns a secret: when serviceClientSecret is empty, Create the service client generates one and stores it in your environment.
azureVaultUri, azureDirectoryId, azureClientId, azureClientSecret, azureKeyName, azureCertificateChain	Optional. Used by the Azure Key Vault folders. See Azure KMS, BYOK, and BYOC.
keycloakIssuer, keycloakClientId, keycloakClientSecret, walletCredentialIdentifier	Optional. Used by Keycloak wallet login (optional). See Tenant federation.

The collection does not ask you to maintain KMS, DID, issuer, verifier, AS, DCQL, credential-design, or status-list URLs, and it has no token variables. Postman manages the access tokens per folder; do not add a manual Authorization header.

When something fails:

Response	Likely cause
401	The folder has no token or it expired. Get a new token on the folder.
403 on a tenant request	The token comes from another tenant or lacks the service's audience. Get a new token on 3. Tenant APIs after changing tenantSlug.
404 on a request with an id in the path	An earlier list or create request did not run. Start the folder at its first request.
Skipped: ... in the console	The request needs an input or an earlier step. The message says which.

Optional external KMS registration

3. Tenant APIs > Azure Key Vault (optional) registers keys that stay in Azure Key Vault. Use your own vault connects the vault as a KMS resource, stores the Entra client secret (write-only), validates the connection, and generates a key in the vault. With azureKeyName set it registers that existing key (BYOK), and with azureCertificateChain also its certificate (BYOC). Use a vault shared by the platform enables a vault the platform operator offered through 1. Platform operator > Share an Azure Key Vault with tenants (optional). The folders never carry private key material. Registered keys and certificates are references: removing them from EDK never deletes them from Azure.

The deployment repository also keeps a dedicated evaluation collection beside the general walkthrough. It is intended for local or explicitly approved evaluation targets only; it is not a public customer-specific artifact and is not a substitute for the route-safe Developer Console collection.