Skip to content
DNSmigrator
betaDNS betaRegistrar betaRegistrarSetup guide checked 2026-09-27

INWX

INWX API credentials setup: use a dedicated INWX sub-account with only the DNS and registrar permissions needed, plus its TOTP shared secret if two-factor authentication is enabled.

On this page

INWX API credentials permissions

Credential type
Username, password, and optional 2FA shared secret
Preview access
Nameserver and domain view permissions
Apply access
Nameserver edit permission; add domain and DNSSEC management for registrar cutover
API endpoint
DNSMigrator uses the provider's fixed API endpoint.

Additional access

The registrar role calls domain update and DNSSEC methods in addition to DNS record methods. A dedicated sub-account limits the impact of storing a password and optional TOTP seed together.

DNSControl id

creds.json TYPE
{
  "TYPE": "INWX"
}

Create credentials

Use a dedicated INWX sub-account with only the DNS and registrar permissions needed, plus its TOTP shared secret if two-factor authentication is enabled.

Access you'll grant

Preview

Nameserver and domain view permissions

Apply

Nameserver edit permission; add domain and DNSSEC management for registrar cutover

The registrar role calls domain update and DNSSEC methods in addition to DNS record methods. A dedicated sub-account limits the impact of storing a password and optional TOTP seed together.

Before you start

  • An INWX account or dedicated sub-account with access to the DNS zones or registered domains.
  • Nameserver view access for preview; nameserver edit access to apply DNS records.
  • Domain and DNSSEC rights if automated cutover should change authoritative nameservers or registry DNSSEC data.

Setup steps

0 of 5 done

  1. Create a dedicated sub-account

    In the INWX customer area, create a sub-account only for DNSMigrator instead of using the main account credentials. Give it access only to the domains being moved.

    Open the INWX customer area

  2. Limit its permissions

    Grant nameserver viewing for preview and nameserver editing to apply records. Also grant domain updates and DNSSEC management only when DNSMigrator should change registrar nameservers and DS records during cutover.

  3. Save the 2FA shared secret

    If two-factor authentication is enabled for this sub-account, save the base32 TOTP shared secret shown during setup. A current six-digit code is not the shared secret. If you no longer have the seed, create a dedicated sub-account without 2FA rather than disabling it on the main account.

  4. Choose Production or OT&E

    For real domains, leave Use the OT&E sandbox off. For tests, create credentials at ote.inwx.com, turn Use the OT&E sandbox on, and use only data from that test system; OT&E actions are not charged.

    Open INWX OT&E

  5. Paste the credentials

    Enter the sub-account values in Username and Password. Add 2FA shared secret only when that account uses TOTP, then check access.

Troubleshooting

INWX asks for two-factor authentication

Add the base32 2FA shared secret. If it was not saved when 2FA was set up, use a dedicated sub-account without 2FA.

A TOTP login is rejected after another login

INWX does not allow a TOTP code to be reused. Wait for the next 30-second code window, or use a dedicated sub-account without 2FA for unattended DNS and registrar sessions.

INWX denies a DNS or cutover operation

Add the specific nameserver edit, domain update, or DNSSEC permission the operation requires; do not broaden unrelated account rights.

Production credentials fail in OT&E

OT&E uses a separate test database and credentials. Make Use the OT&E sandbox match the account where the credentials and domains were created.

Official documentation

Guide checked against the official documentation on .

Credential fields

FieldRequirementWhere to find it
UsernameusernameRequiredThe dedicated INWX sub-account username, or its separate OT&E username for Sandbox.
PasswordpasswordRequiredThe password for that same INWX or OT&E account.
2FA shared secrettotpSecretOptionalOptional base32 TOTP seed shown when 2FA was configured; do not enter a rotating six-digit code.
Use the OT&E sandboxsandboxOptionalTurn on only for credentials and domains created in INWX's separate OT&E system.

Capabilities

Create zones
Yes
List zones
Yes
DNSSEC
Managed through the API
Minimum TTL
300 seconds
Apex CNAME
No
Read only
No

Record types

  • A
  • AAAA
  • CNAME
  • MX
  • TXT
  • NS
  • SRV
  • CAA
  • PTR
  • ALIAS
  • NAPTR
  • SSHFP
  • TLSA
  • HTTPS
  • SVCB

INWX-only types

  • URL
  • URL301
  • FRAME

These records need translation or review when you move to another provider.

Caveats

  • TTLs must be between 300 seconds and 10 days.
  • Each record value is a separate API call, and INWX limits login attempts, so large zones apply slowly.
  • Accounts with 2FA need the TOTP shared secret, which stores both factors together.

Troubleshooting

INWX asks for two-factor authentication
Add the base32 **2FA shared secret**. If it was not saved when 2FA was set up, use a dedicated sub-account without 2FA.
A TOTP login is rejected after another login
INWX does not allow a TOTP code to be reused. Wait for the next 30-second code window, or use a dedicated sub-account without 2FA for unattended DNS and registrar sessions.
INWX denies a DNS or cutover operation
Add the specific nameserver edit, domain update, or DNSSEC permission the operation requires; do not broaden unrelated account rights.
Production credentials fail in OT&E
OT&E uses a separate test database and credentials. Make **Use the OT&E sandbox** match the account where the credentials and domains were created.

Related links

INWX migration overviewMarketing overview and provider differences.Connect a providerHow connection checks and permissions work.Cloudflare → INWXRoute 53 → INWXAzure DNS → INWXCloud DNS → INWX