Authorizations

A typical setup: one set of logins and passwords and a limited number of IP addresses for authorization.

login:password: scripts and mobile clients with dynamic IP. IP whitelist: servers with stable static IP. Both can coexist on the same order — they are separate auth records.

Connections start failing immediately. Call change-authorization with the new ip to update the record without recreating it. In-flight connections drop within seconds.

Only for that credential set. Other auth records on the same order keep working.

Yes. /auth/list returns login and password in plaintext for every authorization on the account, alongside id, active and orderNumber. For IP-whitelist records the ip is also returned. There is no separate "reveal" endpoint — listing is the recovery mechanism.

If you'd rather rotate than recover, use change-authorization to set a new password.

No — by default new orders authenticate with your shared account-level credentials. To get a unique login:password bound to a specific order, pass generateAuth=Y to /order/make (or /prolong/make on renewals). Without the flag, every order reuses the same default pair.

Unique credentials are bound to the returned orderNumber and can be retrieved later via /auth/list. If you skipped generateAuth=Y and want to add a unique pair to an existing order, use /auth/add explicitly.

Single IPv4 and IPv6 addresses are supported. CIDR notation is not supported — enumerate the addresses you need.

Open TCP sessions are dropped within seconds. There is no graceful drain; treat auth deletion as an immediate kill switch.