You are here: Home > Manage IPs and ASNs > RIPE Database > Syncupdates > Synchronous Updates Manual

Synchronous Updates Manual


Syncupdates is the facility of the RIPE Database to enable updates synchronously, meaning, the result is returned immediately to the user. It is meant to be an infrastructure for applications which need to update the RIPE Database and receive the result afterwards.

This document describes the basic usage of the infrastructure that is sends the update and receives the result. An interface can easily be created in any language that has support for "http".


The service can be used by connecting to for the RIPE Database, and for the RIPE TEST database.


The syncupdates frontend is accepts input as either a POST or a GET method. It responds with the response header and the acknowledgement (if any) in text/plain format.

Sending the Update

Syncupdates accepts the following variables:

  • DATA This variable should contain the actual update message.
  • NEW This variable can be either yes or no. If it contains yes, the update will fail if it contains changes to existing objects.
  • HELP This variable can be either yes or no. If it contains yes, the help message of the whois server will be given as the output.
  • ORIGIN This variable should contain the the IP address of the machine submitting the update if it's different from the IP address that is sending the update. It is useful for proxy applications.

For general information about the RIPE Database, please see the RIPE Database Reference Manual.


1. Save the objects you want to send to the RIPE Database in a file, for example objects.txt
2. Sign the text file with your PGP key (this will produce objects.txt.asc):

gpg --clearsign objects.txt

3. Send the file to the RIPE Database:

curl --data-urlencode DATA _at_ objects.txt _dot_ asc

Receiving the Input

After composing the input and sending it as a POST or a GET request, the server will return the usual http headers and the body if an acknowledgement exists.

The first line of the header will give the result of the transaction, in the form of:

HTTP/1.1 (code) (message)

where (code) is a 3-digit number which is a code for the message. The first digit of the code denotes the type of the message. The rest of the digits are unique for all messages:

  • 2XX denotes a successful transaction,
  • 3XX denotes that further action needs to be taken by the user agent in order to fulfill the request,
  • 4XX denotes that the request could not be understood by the server due to malformed syntax,
  • 5XX denotes that the server is aware that it has erred or is incapable of performing the request.

If the code begins with 2, there will be an acknowledgement in the body of the response, in the form of text/plain.

Here are the codes returned specifically by the syncupdates:

  • 200 Acknowledgement follows
  • 413 Data exceeds maximum allowed size
  • 418 No input
  • 419 Command not understood
  • 506 Generic syncupdates error