Axa

Capability: Perils

Market: United Kingdom (Motor Insurance)

Business Capabilities

Use this connector to run a perils check against AXA's LexisNexis DataHub service. The connector accepts a JSON request describing the policy header and one or more subjects (people or organisations, with their addresses, vehicle, claims, convictions and other insurance history), enriches it with the configured vendor credentials, forwards it to the DataHub SOAP service, and returns the enrichment result to the caller as JSON.

The connector lets you:

Run a perils check - submit policyholder and vehicle data and receive AXA's DataHub enrichment output (strategy outputs, data outputs and any vendor messages).
Send multiple subjects - include up to 20 subjects in a single request.
Delegate authentication - the connector injects the vendor credentials, channel, client and insurer identifiers from configuration, so the caller never supplies them.

Exposed Endpoints

All endpoints are served under the base path /axa/v1

Run a perils check: `POST /perils/check`

The endpoint consumes and produces application/json.

Required Request Headers

Content-Type (required) - must be application/json.

The connector does not read any custom routing headers. Vendor credentials and the insurer identifier are resolved from configuration, not from the request.

Vault Configuration

The connector resolves its configuration through the platform ConfigService (backed by Vault). Each deployment requires the following values:

baseUrl - Endpoint of the AXA / LexisNexis DataHub SOAP service. The connector calls it with throwExceptionOnFailure=false so vendor HTTP errors are returned rather than thrown.
username - DataHub service username, injected into the request header.
password - DataHub service password, injected into the request header.
header.type - The type value injected into the request header, for example E.
header.channel - The channel value injected into the request header, for example IQ.
header.client - The client value injected into the request header, for example Y00015.
scid - The insurer SCID injected into the request header's insurer list, for example D00135.

Platform infrastructure values (app.vault., app.cma.url, app.payload.max.size, app.loglevel.) are set in application.properties. The default maximum incoming payload size is 5 MB, configurable through app.payload.max.size (in KB).

Authentication

The connector handles vendor authentication server-side. The caller never supplies a vendor credential.

At request time the connector sets the following header fields from configuration, overwriting anything the caller may have sent: type, channel, client, username, password, and a single insurer entry with the configured scid. The enriched request is then marshalled to XML and sent to the DataHub service using the SOAP operation iiProcessRequest.

Perils Check Flow

The caller sends POST /perils/check with a JSON body containing header and subject data.

The connector validates the body. The header object must be present, but its inner fields are not validated because the connector injects them. Each subject is cascade-validated: type, name and address are required, and each address requires addressLine1.

The Camel route callCheckPerils enriches the header with the configured type, channel, client, username, password and insurer scid, then sets the SOAP operation (iiProcessRequest) and namespace (http://datahub.lexisnexisrisk.com/schema).

The request is marshalled to XML and sent to the DataHub service at baseUrl. Because the route uses throwExceptionOnFailure=false, a vendor HTTP error does not raise an exception; the vendor response is still unmarshalled and returned.

The XML response is unmarshalled back to JSON and returned to the caller.

Request Structures and Samples

POST /axa/v1/perils/check

Body fields the caller typically provides:

header.retrospectiveDate - Date of the check (YYYY-MM-DD).
header.clientReference - Caller-side reference, echoed back in the response.
header.eventType - Event type, for example N for new.
header.productType - Product type code.
subject - One or more subjects (max 20). Each subject supports:
- type (required) - P (person) or O (organisation).
- name (required) - forename, surname, title, and similar name parts.
- dateOfBirth, telephone, emailAddress, and driving-licence fields.
- address (required) - addressLine1 (required), addressLine2, addressLine3, postcode, addressType (C current / R registered).
- vehicle - registration, ownership, mileage, use, value, and related fields.
- claim, conviction, ncd, occupation, additionalInformation.

Example request (minimal valid payload):

POST /axa/v1/perils/check

Content-Type: application/json

Copy

{
  "header": {
    "retrospectiveDate": "2024-09-11",
    "clientReference": "cust-4821",
    "eventType": "N",
    "productType": "POC"
  },
  "subject": [
    {
      "type": "P",
      "name": {
        "forename": "Joe",
        "surname": "Bloggs"
      },
      "dateOfBirth": "1980-01-01",
      "address": [
        {
          "addressLine1": "1 High Street",
          "addressLine2": "Big Town",
          "addressLine3": "Bigshire",
          "postcode": "AB12 3CD",
          "addressType": "C"
        }
      ]
    }
  ]
}

The response mirrors the DataHub enrichment schema, unmarshalled from XML to JSON. Its main elements are header (with iilReference, the echoed client and clientReference, and a message list carrying vendor type/code/description) and insurer (per-insurer enrichment output such as capstone.enrichmentData, strategyOutput with named outputs n and v1 through v20, and dataOutput.product). Vendor-side errors are reported in header.message rather than as an HTTP error.