POST Advertising/Impression

Adds the advertising impression aync.

Request Information

Body Parameters

Impression - The model.

Request body formats

application/json, text/json
application/x-www-form-urlencoded

Sample:

{
  "ContactId": 1,
  "ImpressionSourceId": 1,
  "ContactFileNumber": "sample string 2",
  "ContactFirstname": "sample string 3",
  "ContactLastName": "sample string 4",
  "ContactEmailAddress": "sample string 5",
  "LanguageId": 1,
  "GenderId": 1,
  "Module": "sample string 6",
  "SponsorName": "sample string 7",
  "HyperLinkClicked": true,
  "HyperLink": "sample string 9",
  "MetaData": "sample string 10",
  "IsMobileDevice": true
}

Sample:

Sample not available.

Content Negotiation

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

Versioning

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

Your API account

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.

SSL Transport Security

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.

Caching

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.

Cross-Origin Resource Sharing (CORS)

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/.

Tools

Fiddler2 is a very useful tool to diagnose and aid development when developing against this API. Examine, save, edit and even replay requests captured. Works as an intermediate local proxy server.
Advanced Rest Client for Chrome is super handy. Allows you to finely tweak you REST request. You can even save requests, group them in projects, see the request headers and footers.
VS2012 (updated WebTools >= 2012.2) includes a very useful feature to "Paste JSON in the clipboard as a C#" class. Alternative to this is using the following website: http://json2csharp.com/

Set API-Token

Specify an API Key to be used as the default value for the API-Token header of the Test Client, for the duration of this browsing session.

You may have to refresh your API page to get this value to show in the testing client.

API Key:

Set User Authentication Token

Specify the user authentication Key to be used as the default value for the Authorization header of the Test Client, for the duration of this browsing session.

You may have to refresh your API page to get this value to show in the testing client.

User Authentication Token: