.at

API commandsExtensionsRestrictionsNIS2

API Commands

Please find in the following a set of the most commonly used standard API commands in order to register, modify, renew, and transfer a domain name.

AddDomainModifyDomainRenewDomainDeleteDomainTransferDomainRestoreDomain

Domain Registration

(API Command reference » AddDomain)

Command

command         = AddDomain
domain          = yourdomain.at
period          = (INT)
ownercontact0   = (CONTACT)
admincontact0   = (CONTACT)
techcontact0    = (CONTACT)
billingcontact0 = (CONTACT)
nameserver0  = (NAMESERVER)
nameserver1   = (NAMESERVER)

Domain Modification

(API Command reference » ModifyDomain)

Standard command

command = ModifyDomain
domain  = yourdomain.at

Change of Registrant

Exception

command       = TradeDomain
domain        = yourdomain.at
ownercontact0 = (CONTACT)

The .at owner change process has adapted the FoA procedure, where an email will be sent to the current and future owner of the domain, who have to approve the owner change. If no agreement is given, the trade request expires. The mandatory form will be omitted.

The registration period will not be affected. Trade requests expire after 10 days!

Sending a new trade request during an already pending trade, will cancel the previous one.

Domain Renewal

RenewDomain is not available for .at TLDs.

.at domains cannot be renewed explicitly. To renew a .at domain you have to set the domain renewal mode or default renewal mode to AUTORENEW or RENEWONCE.

Domain Deletion

(API Command reference » DeleteDomain)

Command

COMMAND = DeleteDomain
DOMAIN = yourdomain.at

For most TLDs there is no difference between AUTODELETE and AUTOEXPIRE. But there is a difference for .at domain names. If a .at domain name is set to AUTOEXPIRE the invoice recipient will be changed to the owner at the registry (billwithdraw). In this case the owner will receive an invoice and has to pay the registry for a renewal. If a .at domain is set to AUTODELETE it will be deleted at the registry.

Domain Transfer

(API Command reference » TransferDomain)

Standard command

command = TransferDomain
domain = yourdomain.at
action = REQUEST
auth = (TEXT)

The authInfo will need to have at least eight characters consisting of one number, one alphabet and one special character.
Standard process

• In the standard AuthInfo process the domain holder who wants to change the registrar, requests an AuthInfo from the losing registrar and forwards it to the new registrar. By sending a transfer request containing the AuthInfo, the new registrar takes over the domain. The transfer is processed immediately
• If the AuthInfo standard procedure does not work, there are two emergency methods for these special cases.
  • The special case token-request and
  • The Emergency-process, if the domain holder’s e-mail address is not working. If the Emergency-process is required, please contact [email protected]

Transfer Request WITHOUT AuthInfo(Token Request)

Exception

command = TransferDomain
domain  = yourdomain.at
action  = request
X-AT-REQUESTAUTHCODE  = 1

The token request for a domain transfer is one of the emergency methods. It can be used, for example, if the auth info does not work or the current registrar is not giving out the auth info to the registrant:

1. The new/gaining registrar requests a token
2. Nic.at sends a token code to the e-mail address of the domain holder. This token is valid for 21 days and is only valid for this specific registrar who requested the token.
3. The domain holder will have to forward the token code to the new registrar.
4. The new registrar will then send a transfer request containing the token code he has received from the holder.
5. The transfer is processed within approximately 5 minutes.

Domain Restore

(API Command reference » RestoreDomain)

Command

command = RestoreDomain
domain  = yourdomain.at

• Restores are possible within 59 days after deletion, if the domain was deleted explicitly with the DeleteDomain command or set to AUTODELETE.
• Restores are not possible if the domain was set to AUTOEXPIRE or was pushed back to the registry with the PushDomain command.

Domain Extensions

X-AT-REQUESTAUTHCODE	1 Only in special cases!

Domain Restrictions

• P.O. box NOT allowed as owner address
• The customer needs to be fully informed about the product, the price, conditions, suppliers etc. before, during and after the order as well as there need to be information about his right to withdraw.
  • According to Austrian law, by registering a .at domain, a contract takes place between Domain-Holder and NIC.at.
• You can find additional legal information regarding .at registrations on the registry website.
• Changes to whois output in relation to GDPR for .at domain names are explained on the registry website

NIS2

nic.at, the Austrian registry, is introducing several changes affecting .at domain registrations and contact data from 1 October 2026.

CentralNic Reseller is updating its systems to support these requirements. Most changes will be handled automatically and will require little or no action from customers.

Changes to Contact Data

• Telephone numbers will be mandatory: A valid telephone number will be required for .at contacts. CentralNic Reseller already requires telephone numbers and validates their format, so no action is required.
• Fax numbers will no longer be accepted: You can continue to store fax numbers in your CentralNic Reseller contacts. When a contact is used for a .at transaction, our system will automatically exclude the fax number to prevent the registry from rejecting the transaction.
• Contact details can no longer be hidden: The Registry is discontinuing the option to hide phone numbers and email addresses. CentralNic Reseller will therefore stop supporting the X-UNDISCLOSE parameter for .at contacts.
  For legal entities, these details will be displayed in WHOIS. Organisations should use generic email addresses, such as [email protected], instead of personal email addresses.

Risk-Based Contact Verification

nic.at will use a risk-based process to identify contact data that may be inaccurate or incomplete. This does not mean that every .at contact will require additional verification.

A technical algorithm will identify potentially inaccurate data and refer it to the responsible registrar for review. The registrar must assess the accuracy and completeness of the data and correct it where necessary.

CentralNic Reseller will forward the relevant X-VERIFICATION* parameters to nic.at.

FAQ

Questions	Answers
We already use CentralNic Reseller email verification. Is that sufficient for .AT?	Yes. nic.at do not prescribe how verification must be carried out in practice. However, accounts with obviously incorrect or fake email addresses can and will be selected for review as part of their risk-based verification process.
Will every .AT contact be reviewed?	No. nic.at will use a risk-based process to identify contact data that may be inaccurate or incomplete. Only the contacts selected through this process will be referred for additional review.
How can successful verification be reported?	CentralNic Reseller will forward the relevant X-VERIFICATION* parameters for reporting a successful verification to nic.at. The verification method must be supplied as free text. For example, “Passport and registration form received.” Supporting documents must be retained for one year in case nic.at or the relevant authorities request them.
What happens if verification is unsuccessful?	Only successful verification can be reported. If the contact cannot be verified before the deadline, nic.at may apply serverHold, block further registrations using the unverified contact data or delete the affected domain.