Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


angelaripe edited this page · 59 revisions


Welcome to the RIPE Database REST API documentation.

For more information about the REST paradigm, see

If you used the old (beta) API, consider reading the migration guide for old API users.

All the services are accessible via HTTPS, and HTTP may only be used for lookups.

Use of the Whois REST API is governed by the RIPE Database terms and conditions.

RESTful URI format

Each object in the RIPE Database has a unique locator URI, in the following format:{source}/{objecttype}/{key}

Supported methods:

Additional services

Content Negotiation

All services support the standard HTTP/1.1 content negotiation method.

The client should specify the desired response format using the Accept: header in the HTTP request. If unspecified, the response defaults to XML. The HTTP response will include a Content-Type: header, and the response body will be encoded in the requested format.

The possible values that you can specify for the Accept header are:

  • application/xml for XML
  • application/json for JSON

Clients can also append an extension of .xml or .json to the request URL instead of setting an Accept: header. The server will return a response in the appropriate format for that given extension.

Status Codes

Client applications should use the HTTP status code to detect the result of an operation. Any error messages will be includes in the response body (see below).

Possible reasons for various HTTP status codes are as follows:

HTTP Status Code Cause
Bad Request (400) The service is unable to understand and process the request.
Forbidden (403) Query limit exceeded.
Not Found (404) No results were found (on a search request), or object specified in URI does not exist.
Conflict (409) Integrity constraint was violated (e.g. when creating, object already exists).
Internal Server Error (500) The server encountered an unexpected condition which prevented it from fulfilling the request.

Error Response

If the request fails, any error messages will be returned in the response body, using the requested Accept format (XML or JSON). This element will not be included on a successful response.

For more details, see Whois Resources.

Request / Response Encoding

Please take into account the following points to avoid unexpected encoding behaviour:

  • The database currently supports latin1_swedish_ci collation. It is supposed to support all ISO/IEC_8859-1 character set ( This includes the basic and also extended ASCII characters (e.g. Å, ç etc.)
  • If input is UTF-8, then the characters are converted to ISO-8859-1, and if this is not successful, question marks replace the unsupported characters. In this case a warning is NOT always included in the response. This will be added in one of the next releases. Unrecognised encodings that cannot be converted to latin-1 will result in an unsuccessful operation.
  • In general, for successful create/update operations, in every interface, the response object will always be the one contained in the input. To be absolutely certain of what's stored in the database, do a follow-up query. This is because some non latin-1 characters may be converted and generated attributes can be updated. This was a design decision to increase the performance of the updates.
  • The response will be in UTF-8.
  • To increase success rate of updates, use UTF-8 encoded inputs. If the input contains characters that belong to the extended ASCII charset, (e.g. Å, ç) and input is not UTF-8 encoded, the update fails. This is because of a limitation of the jersey library we use to handle the updates. Alternatively, use the basic ASCII characters in the object content or use Syncupdates which accepts latin-1 encoding.


The RIPE database is available via the URL:

The TEST database is available via the URL:

Data Model

See Whois Resources.

Update latency

It could take up to 10 seconds before an update becomes visible for lookup or search operations. For non-hierarchical object types (person, role, organisation, ....), the typical latency is less than 1 second. For hierarchical object types (inet(6)num, route(6), domain), it is about 3-5 seconds on average, up to 10 seconds maximum.

A way to work around this is limitation is to rely on the response of the the muting operation in REST API (PUT, POST, DELETE). These all return the object as it appears in the database in their response body after the successful update. This object is never filtered or altered in any way.

Something went wrong with that request. Please try again.