The Zonomi connection uses the API key issued for the DNS account. It does not use the domain's registrar password, an email mailbox password or a WHMCS reseller API key. Keep the provider account's zone inventory separate from the customer ownership that Domain Nexus records locally.
IN THIS ARTICLE
What do I need before connecting my Zonomi account?
Obtain the DNS API key from your authenticated Zonomi account. Check that the account can manage the zones you intend to host and that its current service allowance covers the expected number of zones and records. If another application already uses the key, record that dependency before rotating it. A key shared with another application can affect both when revoked.
01 Connect and inspect
- Open Domain Nexus Servers and add a connection with provider Zonomi DNS.
- Give it a clear operational name identifying the provider account, then paste the secret into Zonomi API key.
- Save the connection and run its connection check. Inspect the provider's available zones using the discovery workflow when you are bringing existing DNS under management.
- Review each candidate zone's actual customer ownership before linking it. A domain being visible to the API key is not evidence that the current WHMCS client owns it.
- Assign the connection to the intended DNS package. Confirm the package's nameserver instructions match the Zonomi service or an already configured vanity nameserver arrangement.
02 Verify a record change
Use a zone you control to add a distinctive temporary TXT value. Wait for the module's job to complete, read the records again and query the authoritative service. Delete only that test record after verification. This proves more than a credential check, because it exercises the record management permission and the connection's actual serving path.
If records appear in Domain Nexus but public answers differ, compare the registrar's delegation with the provider's assigned nameservers. Do not keep importing records to correct a delegation mismatch. If the provider refuses a request, check account access, limits and the current job outcome before retrying. Existing provider-specific automation or vanity nameservers should be reviewed before a bulk reconciliation, because a portable record list does not describe every provider-side setting.