The live OpenAPI endpoint describes the v2 routes, parameters, scopes and idempotency requirements exposed by the installed Domain Nexus release. Use it as the starting point for an integration, then verify the account and provider capabilities relevant to your workflow.
IN THIS ARTICLE
01 Retrieve the installed contract
- Configure a current API credential with
docs:readaccess. - Send
GET /v2/openapi.jsonagainst our confirmed API base. - Read the OpenAPI document inside the successful response's
datafield. The endpoint uses the API envelope rather than returning a bare schema document. - Save a dated copy with your integration release notes and compare it when updating the connector or application.
The generated document uses OpenAPI 3.1. It describes path and query fields, JSON bodies, response models, required scope and whether the kernel requires an idempotency key. Read route-specific notes, especially when a result is asynchronous or a feature is guarded.
02 Use capability checks
Read /v2/capabilities, /v2/profile/permissions and the relevant domain or DNS package data. A route appearing in the contract does not grant your credential its scope or make every TLD and provider support that operation.
The contract may describe both provider and reseller workflows. Master-reseller operations require explicit master authority and an eligible downstream relationship. Ordinary reseller credentials should not call them merely because a generated client includes the methods.
03 Build useful validation
Validate required fields before sending requests, but let the runtime enforce registry-specific rules, ownership and current account policy. Read /v2/domains/requirements for dynamic domain fields and consents instead of freezing one generic registration form.
Treat declared asynchronous responses as workflow states. Code generation can produce request objects, but your application still needs operation polling, idempotency storage and correct customer-facing completion handling.
04 Example: extract the OpenAPI document from its response envelope
Use the server-side PHP request helper in the API getting-started article in your private PHP integration with docs:read access. The installed Domain Nexus endpoint returns the contract inside data. This example extracts the document without saving credentials or assuming the whole response is a bare OpenAPI file.
$result = nabtechRequest('GET', '/v2/openapi.json');
$contract = $result['response']['data'] ?? null;
if ($result['http_status'] !== 200 || !is_array($contract) ||
!isset($contract['openapi'], $contract['paths'])) {
throw new RuntimeException('A valid API contract was not returned.');
}
$schemaJson = json_encode($contract, JSON_PRETTY_PRINT | JSON_THROW_ON_ERROR);Read the result: Use schemaJson as the schema content when passing the contract to a compatible tool. Passing the outer data/meta envelope to an OpenAPI parser can fail even though the API request itself succeeded. Keep the retrieved release and date with your integration change record.
Generated client code still needs account capability checks, idempotency storage and asynchronous completion handling. A documented route is not permission for your credential to call it. Validate the actual required workflow before deploying a generated client into paid domain operations.
How should I handle the API response envelope and binary downloads?
Normal results use data and metadata, while errors use a structured problem response. Downloads can return binary bytes with their own content type. Do not force every response through a JSON parser without checking the status and content type.
If a downloaded schema and a live response disagree, preserve the request ID and installed version and investigate before deploying a workaround. Use the current live endpoint instead of assuming an old static specification file is authoritative for the running release.