Overview

Our APIs are JSON based and used for issuing and managing insurance policies across a range of products. The heart of our API's are designed to integrate your partnership with us across all of our global entities......

Registration

This API will provide functionality to register the new customers information.

Policy issuance

This API will provide functionality to issue the policy.

Travel offer

This API will provide functionality to create a offer.

Quotation

This API will provide functionality to create a quotation.

The Partner Experience API accepts HTTPS/TLS connections only in order to protect the integrity and confidentiality of any data transferred. HTTP connections are refused - plaintext communication is not supported.

As a further means to secure requests, this API will use the following security measures:

Client ID/Secret using Basic Authentication Header

Follow the pre-requisites steps found on the Home Page to gain access.

Once you have access to the client_id and client_secret, pass the values in the Authorization header with the type Basic to make requests on behalf of a user:

Basic client_id:client_secret

The client_id:client_secret value must be a base64-encoded string.

In case of an invalid token, a 401 HTTP Status Code with code authentication_error will be returned.

IP Restriction

IP Range needs to be provided to be restricted at MuleSoft end

This API uses conventional HTTP response codes to indicate the success or failure of an API request.

In general: Codes in the 2xx range indicate success. Codes in the 4xx range indicate an error that failed given the information provided (e.g., a required field was omitted). Codes in the 5xx range indicate an error with the server.

Error HTTP Status Code Summary

Please refer to each individual resource and method endpoint definition for specific details on the possible status codes returned.

Error Response

Attributes

Error Response Payload Examples

{
    "code": "E10002",
    "message": "Unable to process request - Please contact support team",
    "correlationId": "f890a9b4-48ed-489e-b627-4692f14ad6cd"
}

{
    "code": "invalid_enum",
    "message": "Invalid enum value provided.",
    "correlationId": "8fa98350-5580-11ee-b30b-02c456ad1aea",
    "causes": [
        {
            "message": "/product/insuredType INDIVIDUAL1 is not a valid enum value"
        }
    ]
}

The DDC is committed to continuously improving and expanding the developer experience provided to consumers of this template for Mule API/integration applications. The lifecycle of this template asset is managed using Semantic Versioning.

Where possible, the DDC team will make changes to the API but not change the version number because the changes are not considered to be backward compatible. Such changes can be any of the following:

• Addition of new resources
• Addition of new non-mandatory request parameters of attributes
• Addition of new data fields returned in the response
• Change in the order of data fields returned by the API

There might be some instances in which breaking enhancements need to happen. In such circumstances, a new version is released not to break compatibility. Such enhancements include:

• Inclusion or removal of mandatory parameters
• Restructuring of the API interface

Upon the release of a new version, applications can continue using the old version, allowing the consumer to assess the changes needed. Release notes with all the changes will be provided with every new version, describing all the changes in detail.

Upon upgrading, consumers are required to request access to the new major version of the API. Given the potential breaking changes, consumers are encouraged to perform regression testing against the new version before upgrading to the new API version in production.

The DDC is committed to continuously improving and expanding the developer experience provided to consumers of this template for Mule API/integration applications. The lifecycle of this template asset is managed using Semantic Versioning.Where possible, the DDC team will make changes to the API but not change the version number because the changes are not considered to be backward compatible. Such changes can be any of the following:

• Addition of new resources
• Addition of new non-mandatory request parameters of attributes
• Addition of new data fields returned in the response
• Change in the order of data fields returned by the API

There might be some instances in which breaking enhancements need to happen. In such circumstances, a new version is released not to break compatibility. Such enhancements include:

• Inclusion or removal of mandatory parameters
• Restructuring of the API interface

Upon the release of a new version, applications can continue using the old version, allowing the consumer to assess the changes needed. Release notes with all the changes will be provided with every new version, describing all the changes in detail.

Upon upgrading, consumers are required to request access to the new major version of the API. Given the potential breaking changes, consumers are encouraged to perform regression testing against the new version before upgrading to the new API version in production.