Diagnose API permission errors using the profile and capability endpoints

1. Read the profile and check the recorded reseller status and account context.
2. Read permissions to inspect the scopes attached to this API identity. Empty grants do not imply unrestricted access.
3. Read capabilities to understand what the installation reports for the account, then compare the failed route's required scope in the current OpenAPI contract.
4. Read the stored limit rows if the error concerns a quota or feature restriction. This response is not a live utilisation report for every service.
5. Confirm that the domain, zone or other resource ID belongs to the authenticated account. Use a returned public identifier rather than guessing a database number.

A missing scope requires an authorised credential or role change. A missing entitlement requires a package or service review. A provider refusal requires checking upstream permission or capability. These are separate conditions, even when the visible symptom is an unavailable action.

Keep the original problem code, HTTP status and request reference. After an authorised change, repeat a read before retrying the mutation. For a paid or uncertain operation, reconcile its existing request first so troubleshooting does not create a second order.

Use the server-side PHP request helper in the API getting-started article without substituting an administrator's stronger credential. The following reads require profile:read. Keep the output in your authorised diagnostic view so it reflects the integration's actual permissions and reported capabilities.

$permissions = nabtechRequest('GET', '/v2/profile/permissions');
$capabilities = nabtechRequest('GET', '/v2/capabilities');
if ($permissions['http_status'] !== 200 || $capabilities['http_status'] !== 200) {
    throw new RuntimeException('Account diagnostics could not be read.');
}
$effectivePermissions = $permissions['response']['data'];
$reportedCapabilities = $capabilities['response']['data'];

Read the result: Compare the denied route's required scope with the returned permission information, then review any entitlement or provider restriction. Success here does not mean a domain purchase can complete, the wallet has sufficient available funds or every provider supports every capability.

Retain the original failure code and request reference. If these reads are also denied, inspect credential status and source-address policy through API Access. Do not respond by granting all scopes to every key or retrying an uncertain paid operation with a new business reference.

No. Capability information describes the current account's reported features. Delegating key scopes still checks the caller's grant rights, and a key cannot elevate itself beyond those rights.

No. Public discovery and shallow health do not test your account approval, wallet, provider credentials or ability to register a domain. Use the authenticated evidence and a controlled supported workflow.

• Get started with the current Nabtech Domain Nexus v2 API
• Create a dedicated API application and issue its first HMAC key
• Read Domain Nexus API errors and trace an uncertain request
• Use the live Domain Nexus OpenAPI contract for your integration