1. Authenticate with an identity authorised to manage API applications.
2. POST an application with a descriptive name, such as Customer domain dashboard. Use the appropriate client_type and permitted rate-limit profile where needed.
3. Store the returned application public ID as clientId.
4. POST to that application's keys resource with a non-empty list of permitted scopes. Add an IP/CIDR allowlist and expiry when appropriate for the deployment.
5. Capture the returned key ID and secret once in approved secret storage. Use them together for the HMAC signing method.
6. Test a read endpoint allowed by the new scope set from the real web or worker environment.

A minimal read-oriented key request might contain:

{
  "scopes": ["profile:read", "domains:read"],
  "networks": ["192.0.2.10/32"]
}

The example address is documentation data. Replace it with the integration's actual authorised egress address before using a network restriction. The caller must be allowed to delegate every requested scope.

Application reads expose metadata. Secret material is revealed during issuance, and redacted reads or an idempotency replay may not reveal it again. Treat the initial response as a secure credential handover, not ordinary debug output.

Keep the original idempotency key and request evidence. Inspect the application and authorised key-management state rather than creating untracked keys repeatedly. If a replacement is required, record it and revoke unused credentials through the supported workflow. Store the application ID alongside its consuming installation so future rotation affects the correct integration.

• Sign Domain Nexus v2 API requests with HMAC authentication
• Replace an API key's scopes and network allowlist without locking out workers
• Rotate Domain Nexus API credentials across web and scheduled integrations
• Get started with the current Nabtech Domain Nexus v2 API