Skip to content

Knowledgebase

Migrate an integration from the retired DomainsReseller API to Domain Nexus v2

domain-nexus, development

Nabtech now uses its own Domain Nexus API. The former DomainsReseller integration is retired. Updating only the hostname in an old script is insufficient because authentication, paths, request bodies, identifiers and completion handling have changed.

01 Use the current endpoint

The live base is https://my.nabtech.co/modules/addons/nabtechresellerdns/api/index.php. Append the documented /v2/... route. For example, profile requests go to the base followed by /v2/profile.

Replace old username/token headers and hourly token generation with one supported current method: X-Api-Email plus X-Api-Key, or the documented HMAC X-Auth-* headers. Do not send both credential methods in the same request.

02 Map the business operations

Task Domain Nexus v2 route
Availability POST /v2/domains/availability
Registration POST /v2/domains/register
Inbound transfer POST /v2/domains/transfer
Renewal POST /v2/domains/{domainId}/renew
Nameservers GET or PUT /v2/domains/{domainId}/nameservers
Contacts GET or PUT /v2/domains/{domainId}/contacts
Registrar lock GET or PUT /v2/domains/{domainId}/lock
Synchronization POST /v2/domains/{domainId}/sync

Obtain the owned domainId from the current domain collection. Do not insert an old numeric database ID or a domain name into an identifier path without resolving the current resource.

What must change besides the retired API endpoint?

  1. Send JSON with the correct HTTP method and Content-Type: application/json for mutations.
  2. Read the current operation schema. For example, domain periods use years; old parameter names and addon arrays are not a universal replacement for current fields.
  3. Read registry requirements and obtain the relevant price quote before a registration, transfer or other priced action.
  4. Assign a stable Idempotency-Key to each business request and preserve it for an unchanged retry.
  5. Read data and meta in successful responses and the structured error document on failures. Track returned operation and job references.

03 Validate the replacement

Begin with profile, capabilities and owned-domain reads. Then test one authorised workflow at a time. A 202 response means accepted work, so wait for the operation result and verify domain state before marking an order complete.

For a billing platform, install the current connector published for that platform rather than retaining the old registrar module. Back up host settings, preserve pending-order references and prevent both connectors from submitting the same order.

Retire old credentials and jobs only after the new integration is verified. Review scheduled tasks and monitoring scripts as well as the public checkout path; otherwise an unnoticed old renewal process may continue failing after migration.

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support