Postman Collection and Environment

The customer developer journey is available as a Postman collection. It ships in the deployment repository under postman/ and starts at the platform boundary: authenticate the platform operator, register a tenant, complete the one-time tenant-owner bootstrap, create the tenant confidential client, and obtain the tenant service token. The remaining folders use that tenant token for tenant administration and runtime APIs; wallet tokens are created and used only inside the issuance lane. License installation and first-run setup still have to be complete, but no second manual login is required once the bootstrap credentials are supplied.

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.
2. Confirm the license and first-run platform setup are complete.
3. Fill in baseDomain, tenantSubdomain, tenantName, and the platform operator credentials. platformUrl is derived as https://platform.<baseDomain>; tenant URLs are derived as https://<tenantSubdomain>.<baseDomain>.
4. Run folders 01 through 04 in order. They authenticate the platform, create the tenant, automate the owner bootstrap, create the confidential client, and store tenantAccessToken from the token response.
5. Continue in order: create designs (11), create standalone status lists (12), configure issuer credentials (13), issue (15--20), create DCQL (21), configure trust (23), then verify (22). Each folder description links back to its guide and each missing prerequisite reports the exact request to run next.

Variable	Meaning
baseDomain	Customer-controlled base domain. The gateway must terminate TLS for platform.<baseDomain> and *.<baseDomain>.
tenantSubdomain, tenantName	Tenant identity used by the onboarding folder. The tenant gateway host is <tenantSubdomain>.<baseDomain>.
operatorEmail, operatorPassword	Platform operator credentials used for sign-in and tenant administration.

The collection deliberately does not ask you to maintain separate KMS, DID, issuer, verifier, AS, DCQL, credential-design, or status-list URLs. It derives those from baseDomain, tenant onboarding output, and /api/platform/bootstrap/v1/runtime-config/admin-console, then stores the discovered API bases as collection variables for later folders.

Optional external KMS registration

The collection also contains a disabled-by-default folder for registering references to existing external KMS keys and public certificates. Replace its collection-local provider, alias, optional kid, provider certificate id, and public DER placeholders only when the target tenant has an active and authorized external provider. The folder never carries private key material, credentials, opaque secret handles, or provider locators. Its DELETE examples remove only the local EDK references and do not delete provider resources. Repeating DELETE after the local reference is removed is idempotent and returns HTTP 204.

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.