WHOIS REST API
Clone this wiki locally
Welcome to the RIPE Database REST API documentation.
For more information about the REST paradigm, see https://en.wikipedia.org/wiki/Representational_state_transfer.
If you used the old (beta) API, consider reading the [migration guide for old API users](WHOIS REST API Migration Guide).
All the services are accessible via HTTPS.
Use of the Whois REST API is governed by the RIPE Database terms and conditions.
Each object in the RIPE Database has a unique locator URI, in the following format:
Sourceis the database source (e.g. RIPE).
Objecttypeis the object type (e.g. inetnum)
Keyis the primary key(s)
- Normally key is a single attribute value.
- Use the
nic-hdlattribute value for person or role object types.
- Combine the
route(6)attribute value and
originattribute value for route or route6 object types (e.g. route 22.214.171.124/23AS3333).
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 request must include a
Content-Type: header for POST, PUT and DELETE. 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/Content-Type header are:
Clients can also append an extension of
.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.
Client applications should use the HTTP status code to detect the result of an operation. Any error messages will be included 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.|
|Method not Allowed (405)||Invalid resource specified (e.g. trailing slash).|
|Conflict (409)||Integrity constraint was violated (e.g. when creating, object already exists).|
|Unsupported Media Type (415)||Unsupported/missing value for Accept/Content-Type header.|
|Internal Server Error (500)||The server encountered an unexpected condition which prevented it from fulfilling the request.|
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.
Please take into account the following points to avoid unexpected encoding behaviour:
- Objects are stored using the latin-1 (ISO-8859-1) character set.
- If the request character set is not latin-1, then the request body is converted to latin-1. A question mark character ('?' or 0x3F) is used as a substitution character, if the character is outside the latin-1 character set.
- The response should contain a warning, if conversion was necessary. (Ref. known issue #291).
- Unrecognised encodings that cannot be converted to latin-1 will result in an unsuccessful operation.
- To be absolutely certain of what was stored in the database, do a follow-up query.
- The REST API response will be in UTF-8.
- We recommend to use UTF-8 character encoding in all REST API requests, but restrict the content to valid latin-1 characters.
The RIPE database is available via the URL:
The TEST database is available via the URL:
See Whois Resources.
Currently only passwords are supported to authenticate REST API updates, using the 'password' query parameter. Multiple passwords can be supplied in the same request.
The authentication model is explained in the Whois Update Reference manual: https://www.ripe.net/manage-ips-and-asns/db/support/documentation/update-ref-manual#section-54
See also the explanation in "Protecting Your Data in the RIPE Database": https://www.ripe.net/manage-ips-and-asns/db/support/security/protecting-data
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.