The DRS offers a comprehensive Web interface for the management of domains, contacts, hosts and other objects. It also provides an e-mail interface that supports some selected use cases. However, some customers are looking for ways to perform more atomic actions on their objects via a scriptable API, using a well-defined set of key-value based requests and responses (the so-called “Payload” format). For submitting such requests, an API endpoint accepting HTTPS POST requests is available.

The DRS expects the requests to be submitted to the URL listed below. Each request must be a POST request. GET requests are not accepted, as there is a high potential that the request, encoded and attached as a query string to the base URL, would exceed the length limitation of URLs.

The default character encoding is ISO-8859-1. A different character set may be specified in the content-type header field as the charset parameter. Alternatively, the character encoding can be specified by the _charset_ form field. This is a non-standard extension for transmitting the character encoding that is used to encode the other fields. If the browser detects a form field with the mentioned name, the value of this field is automatically replaced by the browser with its character encoding. Therefore, if you plan to create an HTML form for your browser, include the following element:

  <input type="hidden" name="_charset_">

The request must be encoded as application/x-www-form-urlencoded, which is the default way for form submissions. Typically, programming libraries take the load of converting the form fields to this encoding. Responses are sent as text/plain. The character encoding used for the responses are the same as the one that has been used for the request. Please note that if you use a character encoding that is not capable of representing certain Unicode characters, they will be replaced by question marks.

In general, authentication is done via the DRS payload, i.e. with the customer.id and transaction.atp fields within the key-value fields. Alternatively, the authentication can be done by two separate form fields, customer-id and atp, containing the numeric customer ID and the submitting person’s e-mail password, respectively. Please note that the customer.id request field has to be specified in the payload in any case, as it is a mandatory payload field. In addition, the person.id field also must be specified, identifying the person within the customer’s organization submitting the request.

For security reasons, the request must be submitted via HTTPS. This ensures encryption for the transmitted data. Here is a summary of all information you need to know:

This table summarizes the form fields to post:

The actual key-value “Payload” format to be sent to the API endpoints listed above is specified in this dedicated document.