PUT WebsiteUser/EmailAddress Test API

This API supports JSON (application/json) and XML (application/xml) formats, with support for accepting the posting of forms-variables (application/x-www-form-urlencoded) still pending. The content type negotiation is automatically selected based on the Accept and Content-Type headers provided with your request to the API.

For example, to indicate that you will accept a JSON response from an API (provided it actually has a response), you would provide the following Accept header:
Accept: application/json

When submitting content, e.g. POSTing or PUTting XML data to an API that expects the content in the body of the request (as opposed to the URI), you would provide the following Content-Type header:
Content-Type: application/xml

For Documentation: If the version is not specified in the query string of the Help index page (ie. /Documentation?Version=2) then the latest version will be shown here by default.

For API: To make API requests targeting a specific version of the API, you need to append the version number to your Accept header of the HTTP Request. Not providing the specific API version, will always have it default to the latest version and can break your application when changes are added in a new version.

Here's an example of appending the version to the header:
Accept: application/json;version=2

Contact the Web Team to register and create an API account. You will then be issued your "API-Token" and "API Public Key" details.

API-Token (API Key) Once you have your "API-Token" you need to include this base64-encoded API-Token header with all requests made to this API. Failure to do so, will result in a response with HTTP Status 401/Unauthorized and a HTTP ReasonPhrase giving more detail (like "Missing API key header: API-Token").

> Important Note: Your API's public key (and also API-Token) may periodically change (in the event of a security breach or updated algorithms or key sizes, as may be necessary due to newly discovered vulnerabilities). It is therefore important that your design allows for easy updating of the new API-Token and API Public Key, and also have update mechanism for applications already deployed.

It is the responsibility of you, the API consumer, to keep the API Public Key securely stored, and you are obliged to notify us upon of breach (or suspicion thereof) in order for us to generate a new key pair and issue you with new API-Token and API Public Key.

The test platform offers the API over HTTP (non-secured) and HTTPS (secured, but invalid certificate due to the server name being different). However, the production platform requires all API calls to be over SSL, and only a valid certificate from the server should be accepted. You may elect to verify the server identity by inspecting it's certificate and thus avoiding possible man-in-the-middle attack vectors.

This API will respond with Cache-Control headers (as per W3C and RFC standards) to indicate what data can be cached, and for how long.

It will also indicate whether revalidation upon cache expiry is required. The API caching also supports the following headers "ETag", "If-None-Match", "Last-Modified", "If-Modified-Since" and will respond with HTTP Status Code 304 where not modified.

Technical Reference: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.

This API accepts CORS requests, including pre-flighted resource validation.

Access to this server through CORS requests is however controlled by your API subscription. Please honour the "Access-Control-Max-Age" response header.

Technical Reference: www.w3.org/TR/cors/.