#Overview

Services provide the functional capabilities for decentralized identity and ID wallets. They can be created inside of tenants and sub-tenants, then managed through the similar administration interfaces documented on this page.

This section is intentionally focused on service operations—creating instances, inspecting configuration, wiring dependencies, and managing metadata. Use the links below if you need other entry points before diving into the admin details:

#All services have a common set of endpoints

Many of the Enterprise Stack APIs look and behave the same, regardless of whether you are calling the Issuer, the Verifier, a KMS, or another service. Every endpoint is mounted under /v1/{target}/{service-name}-api/..., where target is the dot-separated path to the organization, tenant, and service instance (for example acme.sandbox.issuer-eu).

#1. Provisioning & lifecycle

All services are created, listed, or deleted through the resource-api.

• Service creation – create a service using the /resource-api/services/create endpoint.
• View Service Resources - list child service resoures using the /resource-api/resources/list endpoint.
• Service deletion - delete a service (and optionally everything underneath it) using the /resource-api/resources/delete and /delete-recursive endpoints.

All all service provising & lifeclye operations go through the same controller, you never have to learn a service-specific “create” endpoint.

#2. Configuration

Once a service exists you can always introspect or replace its configuration:

• View Configuration - call /configuration/view on any service to inspect is config.
• Update Configuration - call /configuration/update on any service to update the present config.

This is the way to rotate signing keys, update issuer metadata, point a wallet to a new credential store, etc., without having to recreate the service.

#3. Dependency Services

Services can depend on other services, depending on how your use case is built. For example, the DID Service may require the DID Store Service to persist DID Documents. Each service exposes its dependency management via /dependencies/... endpoints.

• View Dependencies – see which services are linked as dependencies of current service.
• Add Dependency - attach a new dependency service to current service.
• Remove Dependency - remove a dependency service from current service.

If a service does not use any dependency services, these endpoints will simply not be available. To see which dependencies a specific service needs, check its section here.

#4. Metadata management for child resources

Certain services—like KMS, DID, and Credential Store—automatically add a metadata block to their child resources (for example Keys, DIDs, and Credentials). You can tell whether a service supports metadata for its child resources by checking if it exposes /metadata endpoints.

• View metadata – /metadata/view returns the JSON blob stored next to a child resource.
• Set or update metadata – /metadata/set replaces the blob, and /metadata/update applies a JSON Patch style update.
• Remove metadata – /metadata/purge clears the metadata for that resource.
• Query metadata – /metadata/query runs constraint-based searches across all children underneath the service.

This gives you a uniform way to label stored keys, DIDs, or credentials (for example with usage, or environment tags) and then search for them later.

#Get Started With a Specific Service

Check out the service overview page here.