An authorised master can manage supported API credentials for assigned ordinary downstream resellers. Read the credential metadata before issuing or changing a key, and deliver any newly revealed secret only to the intended customer's approved installation.
01 Read and select the credential
Use the master workspace's credential controls or GET /v2/master/client-credentials with the assigned recipient_reseller_id. The response shows metadata, such as the key identity and current version, without recovering an existing secret.
Confirm the reseller company, account email or permitted API username and the installation that will use the key. A custom API email must satisfy the service's ownership and uniqueness checks. Do not take an address belonging to another customer account.
02 Issue or change access
- For a new credential, choose the issue operation and a useful label. The child must be active.
- For an existing credential, use its
key_idand currentrow_version. Update permitted labels or IP restrictions through the supported controls. - For rotation, revocation or deletion, supply the exact
ROTATE,REVOKEorDELETEconfirmation respectively. - Store an issued or rotated key at its one-time reveal. It is not retained in a recoverable form for later display.
- Update the intended connector and scheduled environment, then verify a read-only profile request as that child.
Common questions
Does rotating preserve the old key during a grace period?
Do not assume an overlap window. The email/API-key rotation replaces the existing secret. Coordinate the consumer update and verify the actual result.
Can this workflow issue another privileged master key?
No. Downstream credential management does not grant master access, and privileged master identities cannot be managed as ordinary child credentials.
Can I rely on an Idempotency-Key to repeat a lost rotation response?
This master credential route has no kernel idempotency flag. Read the current metadata and resolve the uncertain result before another mutation. A second rotation can invalidate the key just issued.
How should the key be delivered?
Use the approved secure channel or secrets system for the identified customer. Keep it out of public packages, shared tickets and screenshots. If the reveal was lost, follow the controlled replacement workflow instead of asking support to recover the old secret.
Related articles
- Rotate Domain Nexus API credentials across web and scheduled integrations
- Investigate a downstream reseller issue within the master account's assigned scope
- Replace an API key's scopes and network allowlist without locking out workers
- Prepare a new reseller account for its first live domain order
- Bootstrap and rotate credentials for a Blesta module account