After you submit an update using our update protocol the following status code(s) will be returned. If updating more than one host or group, multiple status codes will be returned separated by a new line in the same order they were submitted.
|good IP_ADDRESS||Success||DNS hostname update successful. Followed by a space and the IP address it was updated to.
The IP address returned will be the IPv4 address, if an IPv4 is supplied. If IPv4 and IPv6 are both supplied, both ips will be returned in a comma separated list. If only an IPv6 address is supplied, an IPv6 address (only) will be returned.
|nochg IP_ADDRESS||Success||IP address is current, no update performed. Followed by a space and the IP address that it is currently set to.
The IP address returned will be the IPv4 address if an IPv4 is supplied. If IPv4 and IPv6 are both supplied, both ips will be returned in a comma separated list. If only an IPv6 address is supplied, an IPv6 address (only) will be returned.
Note: Excessive nochg responses may result in your client being blocked.
|nohost||Error||Hostname supplied does not exist under specified account, client exit and require user to enter new login credentials before performing an additional request.|
|badauth||Error||Invalid username password combination.|
|badagent||Error||Client disabled. Client should exit and not perform any more updates without user intervention.
Note: You must use the recommended User-Agent format specified when Submitting an Update, failure to follow the format guidelines may result in your client being blocked.
|!donator||Error||An update request was sent, including a feature that is not available to that particular user such as offline options.|
|abuse||Error||Username is blocked due to abuse. Either for not following our update specifications or disabled due to violation of the No-IP terms of service. Our terms of service can be viewed here. Client should stop sending updates.|
|911||Error||A fatal error on our side such as a database outage. Retry the update no sooner than 30 minutes.
A 500 HTTP error may also be returned in case of a fatal error on our system at which point you should also retry no sooner than 30 minutes.
What to do with the result codes
The client must interpret the status codes and act accordingly, providing the end user with some useful information. This will help in debugging problems. The client should only schedule future updates when it receives a "Success" return code. Any "Error" return codes will require user intervention to correct the problem with their configuration.
The most common errors are bad user input, such as misspellings and incorrect passwords. The update client must not continue sending updates or use our IP detection system if it receives an error return code. Your client should instead notify the user of the problem have them attempt to correct it before trying again. If the error return code requires No-IP intervention your client should tell the user to contact our support team. See the status code descriptions for return codes that require contacting No-IP Support.