Overview

Our APIs are secured by industry standard authentication/authorization which support OAUTH 2.0 and OIDC Flow

Get Access Token

URL: /auth/token

This API is use to retrieve Access Token using partners username/password

These steps assume you are already registered to use the Zurich Exchange. If you are not, please Register for an account in order to proceed. If this is your first time using one of our API's we suggest to go through our API Template page where you can find information on the basic concepts used throughout this API.

Request API access

• If you have not already done so you will need to obtain an application client identifier and secret that you use to interact with this API. This can be obtained from the Zurich Exchange by selecting this API and click "Request API access".
• Select the "Instance" you wish to access - i.e. for a specific test environment or Production. Depending on the type of API you may have multiple options or just one available to you.
• Select the "Tier" that you wish to access. The tiers represent the policies that might apply to the API (i.e. Bronze may be restricted to n calls per minute). Tiering for most APIs is set as Bronze (1 API call per second - designed for testing and development), Silver (10 API calls per second - for larger volume scenarios) and Gold (100 API calls per second - use for Production scenarios).
• Click Next
• "Select an existing application" from the dropdown(if you have already requested access for other APIs), or "Create a new client application" and add a meaningful name. This Client Application will be linked to the key you'll be issued with for this API.
• Read the Terms & Conditions and check the box to accept these.
• Click "Request Access" to complete the request.
• Once submitted your access request will be reviewed and approved within 1 working day. You will receive an e-mail upon approval containing the client credentials required to access this API.

Make your first API request

In this example we will use the HTTP POST method to invoke the offers resource and Receive available plans and premium response, using the information provided in the request.

The steps described here are generic and follow cURL based conventions, however feel free to use your preferred API client.

1. Set the API endpoint based on target environment instance, for example : https://test-ap.capi.zurich.com/zjp/apdn/e/partner/v1/dev/api/personal-accident/offers``
2. Set your client identifier and client secret in the HTTP Authorisation header as described by the Authentication page.
3. Set a HTTP Content-Type header with value: application/json
4. Set a JSON request payload as shown below.

{
    "username": "abcd",
    "password: "abcd"

}

cURL examples

Example request

Using cURL it is possible to send the example request detailed above using the command shown below:

Note:__\_ replace clientid and clientsecret placeholders with your actual client credentials._

curl --location 'https://test-ap.capi.zurich.com/zau/apdn/e/authentication-service/v1/dev/api/auth/token' \
--header 'X-Z-Product: PersonalAccident' \
--header 'X-Z-Country: JP' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic OTkxNzA2ODA0Njc0NGZhZTljNTFhZmEwMTI3ZWUxM2Q6NTIyNzgwZUQ5NWQxNGUzMDk1RTkzMGEyMjAxMUE5NEM=' \
--data '{
    "username": "abcd",
    "password: "abcd"

}'

Example response

A successful request for this endpoint will return a 204 No Content status code, and hence no response body.

The Australia Partner 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.

API access is governed through an Anypoint Platform enforced Client Id/Secret policy.

Client ID/Secret

Complete the pre-requisite steps on the Getting Started page to obtain API client credentials.

The Client Id/Secret is enforced using the Basic Authentication scheme. This requires the client_id and client_secret values are communicated using the standard HTTP Authorization header with the authorization type to Basic.

The format of the Authorization header is as follows:

Basic client_id:client_secret

In accordance with the Basic Authentication specification the client_id:client_secret value must be passed as base64-encoded string as shown below:

Basic Y2xpZW50X2lkOmNsaWVudF9zZWNyZXQ=

The API will return a 401 HTTP Status Code with code authentication_error in case of an invalid value or credential.

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.

Multiple API environments are supported.

These environments have access to different data as listed below: