Skip to content

Knowledgebase

Replace an API key's scopes and network allowlist without locking out workers

domain-nexus, development

The key-scope and network endpoints replace complete sets. Build the intended final list before submitting either request. Sending only the one permission or address you want to add can unintentionally remove everything else that the integration still needs.

01 Prepare the change

Method Resource Scope Idempotency-Key
PUT /v2/api-clients/{clientId}/keys/{keyId}/scopes keys:write Required
PUT /v2/api-clients/{clientId}/keys/{keyId}/networks keys:write Required
  1. Identify the API application and exact HMAC key used by the affected integration.
  2. Inventory the read and write routes it calls, including scheduled jobs, quote requests and supporting metadata reads.
  3. Determine the real outbound addresses used by its web server and workers. A customer's browser address is irrelevant when your server makes the API request.
  4. Prepare the full intended scopes list and full networks list. Each scope must be within your own delegation rights.
  5. Apply one reviewed replacement with its required idempotency key. Verify a permitted read from the deployed environment before proceeding to the next change.

The network body is an array of IP addresses or CIDR ranges:

Structured data example
{
  "networks": ["192.0.2.10/32", "2001:db8::10/128"]
}

These addresses are examples. Use your real authorised egress values and keep any administrative recovery path available.

Does an empty network list deny every request?

No. In this endpoint an empty list removes the network restriction. It does not represent a deny-all policy. To retire an integration, revoke its key using the supported key-management workflow instead of relying on an empty allowlist.

What if I lock out the current caller?

Use an independently authorised account or credential-management interface to review and repair the intended restriction. Do not attempt to bypass ownership checks with another tenant's key. Check NAT, IPv6 and worker egress before broadening the list.

After a scope replacement, verify both an allowed operation and the intended absence of unnecessary access. Keep the final list with the integration's operational documentation, so a later rotation preserves the deliberately chosen permissions rather than restoring an obsolete broad key.

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support