loader
Image
gto-s-third-party-liability_icon

Third Party Liability Quote

1.0
Average Rating
0
No votes yet
Zurich's Third Party Liability API will allows brokers/partners to submit quote requests for products to support online marketplace sales

Documentation
Home

Zurich's Third Party Liability API allows brokers/partners to submit quote requests for a product that supports third party liability for sales on popular online marketplaces. This will return a valid price for the product and indicate any referrals that are subject to the quote.

How this can help you

Partner broker agencies can use this API to speed up their online processes by integrating the digital quote creation into their applications. This API accelerates the time for direct quote evaluation, reduces the turnover period for quote and the effort required, while keeping the focus on Quotes that require a proper risk assessment through the Underwriting process.

How does it work

External broker agencies will be able to integrate with our core Underwriting system and, through Zurich eXchange register for access, understand how it works and be aware of the latest updates and functionalities on this API.

resources/hla-3912f241-4bbb-4f37-ab81-780737069da7.png

In order to use this API is important to understand the detail on the possible products in place for quote requests. For this reason we suggest you review the Product Catalogue page to understand the available products and the required fields to be provided during quote process creation. Please contact us if you require more information.

How do I get access

New applications wishing to use the service can request access via the API Exchange. Details of this process are outlined in the Getting Started page. Once the API Owner accepts your request you will be issued with credentials to call the API.

Getting Started

All our API’s are designed to be easy and fast to consume! You can play with them from day 0 through our built in mocking services available through the Contact tab. You can also review Terms and conditions and Request Access as described below if you want full access to the API.

Step 0. First time

If this is your first time using one of our API's we suggest you review the below instructions.

Step 1. Request API access

Click on the "Request Access" (you'll need to be a Registered User to see this) linked to the API. You then set up a Client Application to which your API will be registered.

  1. Select the Environment you want to access (more details on our Environment page)
  2. Select the right Tier for your application, if relevant you can find more information on Pricing page/
  3. "Select an existing client application" or "Create a new application" that will be allowed to call this API, providing details allowing you to distinguish your registrations across different applications.
  4. Read the Terms & Conditions and check the box f you accept them
    • Terms and conditions vary between API's, it is important understand the information to prevent any API misuse. You can find the details on the Terms and conditions page.
  5. Once submitted your access request will be considered and we should contact you within 48hrs, either with the registration or with a request for further information.
Step 2. Use the API

Once your Client Application is approved, you can obtain your credentials from the My Application page. You can visit our Authentication page to understand which authentication mechanism should be used to interacting with our API as this can vary by API..

You can use this API through your preferable wrapper, MuleSoft, Azure API, Java, Python... Just follow our API Run Flow to understand how to use it, or explore the Console tab to see our API documentation in more detail.

Step 3. Maintain your Application

We are always looking to improve our API's, this means that is also important for you to know how this API can evolve and how we manage it. The Versioning page provides detail on which versioning model is being used, and how this can affect your applications.

Step 4. Provide feedback and get support

Visit the Support page to know how to interact with us, but while you are here, feel free to use our Reviews section

Step 5. Decommissioning

We hope you are not thinking about it but we recognise things change. If you need to delete your access, simply delete your Application on "My Applications" page, and you will be unregistered from this API.

Product Catalogue

This page describes the current product offer that can be subscribed through the Zurich Third Party Liability API, allowing the understanding of the mandatory declarative questions and available products available to you.

Product Structure

Before going into details of the actual product catalogue is important to understand the product structure, which is agnostic to the product, as presented on the following diagram:

resources/product_structure-5f23114d-1426-4286-b8bf-c1a0b1e3548f.png

The product structure defines the following entities:

EntityDescription
QuoteRoot entity which will contain all the relevant information to allow a quote creation and later purchase and policy issue.
One key identification on this layer is the productId which will represent the commercial package we want to quote, available products can be found on the Product Offer section.
Policy linesThe policy lines will contain the actual products subscribed, identified by the id, if a commercial product offers multiple products, those can be sent / configured through the specific policy line information
Insured objectContains the actual details of the object being insured, as per the provided category / sub-category of product
Declarative Questions AnswersThis section will contain the specific information that should be provided by the insured entity, allowing the evaluation of the quote and final pricing. Based on the policy line id in use, different declarative information might be required.
InsuredsDetails of the entity the quote is being created for (which will be insured)
Underwriting informationProvides underwriting information, allowing a specific quote to be forced for manual referral review, and providing the agent username in the Underwriting system
Agency informationProvides information of which agency the quote is being created for
Product Definition

The following table describes the actual product structure (identifiers of the products) and mandatory declarations / fields that would be required to be sent be consumers depending on the product type:

Product Package IdPolice Line IdDeclaration Question IdDescription
QuoteA3PliabilityLiability product for Third Party Liability insurance
countryOfSalesCountry of sales allowed:
- EU-ASIA
- US-CA-UK-IL-CL-AU
- OTHERS
territoryOfSalesTerritory of sales allowed:
- US
- NON-US
Pricing
How am I charged?

There are no charges for the use of this API. There is currently no tiering (throttling and other policies) applied to this API but we reserve the right to apply them in future. We suggest all consumers start with a Bronze tier - this can always be up-rated later.

Authentication

This API is protected by Basic Auth: standard HTTP Authorization header with the authorization type to Basic

The user and password are governed through an our API 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.

Postman

In order to speed up your integration we prepared a curated Zurich Postman collection which you can found on Zurich Postman Enterprise - CC_API_Centre for Enablement.

If you are a Zurich employee / contractor and you don't have access, please visit Zurich Get Postman link, and take the opportunity to visit our C4E Postman Best Practices while your access is being approved.

Configure your environment variables

As defined on the Postman Best practices, this is a shared Collection, which is already curated for initial use.
When using the provided collection, please ensure you create your own copy into your team workspace and don't update the collection.

Only current values in environment properties can be changed as presented below:

postman_collection_environment

Run your postman collection

Once you have configured the environment variables feel free to invoke the available methods and retrieve the API details.

Any additional question please contact the C4E team

Errors

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

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

The sections below explain in detail the HTTPS status codes returned by the API and the error response message returned to the user.


Error HTTP Status Code Summary

The table below contains all the possible HTTP status codes that the API returns, however, one should refer to each individual resource and method endpoint definition for specific details on the possible status codes returned.

Status CodeDescription
400 Bad RequestThe server could not understand the request due to invalid syntax.
401 UnauthorizedInvalid token. The server was unable to authenticate the user.
405 Unaccepted HTTP MethodThe method received in the request-line is known by the origin server but not supported by the target resource.
406 Not AcceptableThe service is unable to fulfil the request based on the Accept header provided.
415 Unsupported Media TypeThe media format of the requested data is not supported by the server.
500 Internal Server ErrorAn internal server error was observed.
502 Bad GatewayThe server encountered received an invalid response from an inbound server it accessed while attempting to fulfil the request.
503 Service UnavailableThe server was unable to handle the request due to a temporary overloading or maintenance of the server.

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


Error Response

Independently of the error scenario a common error structure will be returned, allowing consumers to manage error results through a common structure, below the specific attributes that compose this error message structure can be checked in more details.

Attributes
Field NameDescription
codePattern based scheme that identifies a specific and unique error condition. Typically human readable but more suited for machine processing.
messageHuman readable description of the error that occurred that is not intended to be machine parsable.
correlationIdProvide ability to rapidly identify and trace distributed request processing. ​
sourceOptional. Describes the source of the error; used to indicate the error originated elsewhere or self-reference when error was generated internally or in direct consequence of downstream events.
source/nameImplementation provider defined name for the API, service or system.​
source/layerImplementation provider defined name for the API, service or system.​
causesOptional. Describes the source of the error; used to indicate the error originated elsewhere or self-reference when error was generated internally or in direct consequence of downstream events.
causes/codeOptional. Pattern based string that identifies a more fine grained error condition, which contributed to the general/parent error code above. ​
causes/messageMandatory. More specific information on the failure cause. ​
causes/fieldOptional. A JSON Pointer (RFC6901) that identifies the entity or entity attribute responsible for the more specific error code and message. ​​
causes/sourceOptional. See “source” object definition above ​​​
Error Response Payload Examples
{
  "code" : "RESOURCE_UPDATE_FAILED",
  "message" : "Cannot update User account groups",
  "correlationId": "3d9445ca-dd6c-4fe2-b93d-c23423f0d612",
  "causes": [
    {
      "code": FAILED_UPDATE_SECURITY_TYPE_DEFAULT,
      "message": "Failed to set security type to 1"
    }
  ]
}

Environments

Exchange Name: gto-s-third-party-liability


Environments available.

This API is provided as System API with the view that consumers will integrate it either directly into their application or their own business process APIs.

URLs

This API is published to the following environments but may be made available in the following environments:

Additional environments are provided for development of the API but access will only be granted in consultation with the API owner.

API Run Flow

This API provides you the capability to integrate with GTO Third Party Liability underwriting system:

API Flow

  • After ensuring API access (more information can be found in Authentication page), you will be able to invoke our API.
  • Validate the base URL from the Environment page to obtain the base URL for your API call.
  • Go to our API Documentation page to get examples for common Languages / Wrappers, below you can find a typical interaction flow with the API:
    • Invoke POST /parties/sellers to create a new seller for which new quotes can be requested.
    • Invoke POST /quotes to create a new quote.
    • Invoke GET /quotes to search the available quotes based on the available filters (query parameters).
    • Invoke GET /quotes/{quoteId} to retrieve one specific quote details.

Common notes

While invoking an API, traceability is an important point, allowing the identification of possible issues and miss-usage on our analytics system, for this reason, always ensure an unique identifier is supplied for X-Z-Conversation-Id and X-Z-Request-Id, which will allows a quicker analysis of the requests.

Versioning

Zurich aims to continuously improve and expand the developer experience and the functionality of its APIs.

Where possible we will make changes to the API with no impact to you because the changes are not considered to be non breaking. 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.

If changes are inforce or planned, they will be detailed below.


VersionActivePlanned decommissioning dateAdditional remarks
v1YesNot applicable-

Please refer to the API instances section of the Console to view which minor version is currently in use per environment and Decommissioning for more details on the version upgrade process.

Support

Contact our API Support team or your local Zurich service contact for more information or support.

If you are already having a specific issue, maybe our Known Issues section may help you:


Known Issues

There is nothing to report!

Decommissioning

API Minor / Patch / Implementation upgrade

Our APIs evolve to support richer functionalities and keep up with business requirements. This can lead to API Specification changes which do not impact consumers. We follow the following process to make you aware of new functionalities :

resources/decommisioning_minor_version-c11d571e-94f2-4e43-8393-0eda17b356a2.png

StepDescription
Notify API Minor / Patch / Implementation ReleaseAs a new minor/patch version or API implementation change is deployed in Acceptance, all will be notified of the API changes
Execute Application regression testsConsumer applications can use Acceptance environment to execute regression tests and validate that no impact on current functionality exists due to the new version
Note: as minor/patch/implementation updates are executed in order to prevent any consumer impact, this step is not mandatory, although it is highly recommended to prevent Production impact, being of high importance automatic regression tests for this scenarios
Issues detected?As the regression tests are made on the consumer side check if any issue occur
C4E Issue submission & regression testsIf an issue is detected during this phase, please Contact the API Owner to have the right level of support and prevent production impact
Production Deploy Grace Period - 1 weekAs per the defined grace period, Production deployment will be hold during the defined SLA to allow consumers regression tests validation
Notify Production UpgradeAs the SLA for production deployment is reached the new version will be promoted into production

Note: Hot-fixes are by nature an exception process, and will not follow the defined process (e.g.: emergency releases as experience during Log4J2 vulnerabilities). For those scenarios, a specific process will be followed.

API Major release / Decommissioning

A minor/patch upgrade version approach will be the preferable approach, although, in some scenarios that approach cannot be followed due to external factors as for example:

  • Breaking changes on end systems due to system upgrade
  • Change of API system provider leading to major data changes not compatible with current version
  • New functionalities that forces additional data to be provided

As running parallel API versions requires additional Infrastructure and Support activities, older major releases will be decommissioned as per Terms of Service SLA, below is presented the high level process and flow in use to manage the overall decommissioning activities:

resources/decommisioning_major_version-53dacbe2-8500-4e76-a7f7-3bd4da1a3aa3.png

StepDescription
Notify API Major ReleaseAs a new version is available and deployed in Acceptance all subscribers will be notified about the new API Major version
Deprecate previous versionAs a new version is created, previous version Access Request will be disabled, preventing new access request, but allowing existing consumers to continue to use the previous version
Request access to new version in API PortalAs the new version is made available in Acceptance environment, consumers can request access to the new version on API Portal
Execute new API Version integration & Regression TestsWith the new API Version implementation, consumers will have a grace period to adapt existing applications to the new API version, during this grace period consumers should upgrade and execute regression tests to validate current functionality
Deploy to ProductionEven before previous version final decommissioning, both API versions will be running in parallel, so consumers will be able to upgrade to the latest version as per their internal release timelines
API Parallel Run SLA - 6 MonthsDuring the defined SLA time API will co-exist
Notify Production ShutdownAs the SLA for parallel run is reach, a final communication will be sent to inform that previous version will be finally removed

Note: Where, due to external factors API co-existence cannot be met, an exception process will be shared with all API consumers to present the alternatives process, allow feedback, give as much notice as possible and minimize impact

For additional information please Contact the API Owner.

Release Notes

v1.0.0: First Release

Description: First release of the Third Party Liability API

Features:
  • Implementation of the following base paths:
    • quotes: provide the capability to create quotes and search existing quotes
    • parties/sellers: provide the capability to create new sellers
Known service limitations:
  • No Product Catalogue functionality, please refer to product page for more detail on the required information based on the product type
.terms

Global terms

1. Definitions

(a) “Terms”: refers to the API terms of use, i.e. this document.
(b) “API”: refers to the application programming interface offered by Zurich, which may include code, software libraries, software tools, sample source code, published specifications and documentation. API shall include any future, updated or otherwise modified versions.
(c) “API Content”: means information delivered through the API, subject to its appropriate license terms, as identified below, and includes portfolios, policies, claims and risk engineering information.
(d) “API Key”: means the code provided by Zurich that permits the Customer to access the API.
(e) “Documentation”: refers to the online user guides and/or help and training materials that Zurich provides regarding the use of the API.
(f) “Application”: refers to any software application, website, or product developed by the customer that interacts with the API.
(g) “Downtime”: means a period of time during which the API is unavailable and the Customer is unable to use all aspects of the service for which they have permissions. Downtime does not include the period of time when the API is not available because of:
a. a scheduled or announced maintenance outage
b. events or causes beyond Zurich’s control (e.g., natural disaster, internet outages, emergency
maintenance, etc.);
c. problems with Customer’s applications, equipment or data, or a third party’s applications,
equipment or data
d. Customer’s failure to adhere to required system configurations and supported platforms for
accessing the API, or
e. Zurich’s compliance with any designs, specifications or instructions that the Customer provides to Zurich or a third party provides to Zurich on the Customer’s behalf
(h) “Zurich”, “We”, “Our”: being the organization providing the service
(i) “Customer”, “You”, “Your”: being the owner of the application consuming the API service
(j) "Zurich Exchange": the portal that provides access to documentation and registration services related to Zurich APIs.

2. API description

The goal of the API is to provide an easy way for applications to use GTO Third Party Liability API from cloud based services by enabling developers to create applications that integrate with a managed service account service through a global support contract, as described in the API documentation.

3. Agreement to the API terms

The API Terms describe Your rights and obligations as part of using the API. By accepting these Terms or by using the API , You are entering into an agreement regarding the access and use of the API. These Terms apply to the use of the API only and have to be accepted in addition to the Terms and Conditions of the Zurich Exchange. If You do not agree to these Terms you may not use the API.

If You are entering into these Terms on behalf of a company or other legal entity other than Zurich, You represent that You have the authority to bind such entity to these Terms. In that case, the terms “You” or “Your” shall also refer to such entity. If You do not have such authority, or if You do not agree with these Terms, You may not use the API.

Subject to these Terms, Zurich hereby grants the Customer a limited, non-exclusive, non-transferable license (without the right to sub-license) to use the API solely for the purpose of the Customer’s efforts to develop applications to work in conjunction with the Zurich products referenced in the API and for which the API was provided. The Customer shall have no right to distribute, license (whether or not through multiple tiers) or otherwise transfer the API to any third party or incorporate the API in any software, product, or technology.

4. Review of the terms

Zurich reserves the right to amend or modify the Terms at any time. Updates to the Terms will be notified to the Customer and communicated on the Zurich Exchange. The Terms will be under version control and the latest version will supersede the previous versions. You understand and agree that if You use the API after the date on which the Terms have changed, we will treat Your use as acceptance of the changed Terms. If a change is unacceptable to You, You may terminate the Terms by ceasing use of the API.

5. Registration and Access to the API

Zurich provides access to API Documentation and allows the Customer to register for the use of an API via the Zurich Exchange. Once the Customer subscribes to the API and accepts the Terms, a technical API user will be created and issued with a client ID and client secret. This user is not allowed to log in to other Zurich Services and has access to the API only. The client ID and secret are used to request an access token, which contains the scope for accessing the API. Every call to the API must contain the token to access the data.

You may only access the API with the credentials provided to You by Zurich. You will not disclose Your credentials to any person and will be responsible for ensuring they are kept secure. If You become aware of any unauthorized use of Your access credentials, You agree to notify Zurich immediately via the Service Desk. Zurich reserves the right to revoke Your API access should any aspect of the Terms be breached.

6. Changes to the API

All APIs which will be made available will be versioned. Zurich may introduce additional APIs and additional endpoints within these APIs and will endeavour to provide reasonable notice of any new API URLs. Zurich will try to ensure that future versions of the API are backwards compatible, but reserves the right to discontinue support for older versions if major modifications to an existing API URLs are applied. In such cases, this will be managed and communicated under the governance set out with the Change Management process.

7. Use of API

Use of the API is subject to information security policies and procedures of Zurich, which may be amended from time to time.

By using the API and acceptance of these terms, you assert that your use of and the API data is in compliance with your local data laws and Zurich's Security policy.

Your continued use of the API will constitute Your notice of, and agreement to, any amended policies and procedures. When using the API, You may not:

  1. modify, obscure, reverse engineer, circumvent, or disable any element of the API or its access control features
  2. disclose, share, or transfer Your access credentials to any third party
  3. transmit any viruses, worms, defects, Trojan horses, or any other malware through Your Application or use of the API
  4. use robots, spiders, crawlers, scraping or other similar technology to obtain any information beyond what Zurich provides to You under these Terms/
  5. use the API in a manner that exceeds reasonable request volume, constitutes excessive or abusive usage or otherwise fails to comply or is inconsistent with any part of the Zurich API documentation.
  6. infringe, misuse, or claim ownership of Zurich intellectual property or intellectual property rights therein
  7. use it with an Application that is offensive, abusive, libelous, harassing, threatening, discriminatory, vulgar, pornographic, unethical, unlawful, or otherwise inappropriate as determined by Zurich in its sole discretion
  8. assign or transfer Your rights or obligations under this Agreement

If We believe that You have attempted to exceed or circumvent these limitations, We may temporarily or permanently block Your ability to use the API.

8. Monitoring and Auditing

You agree that We may collect certain usage data and information related to Your use of our API and that We may use such usage data for any business purpose, internal or external, including providing enhancements to API, providing support, verifying Your compliance to these Terms or otherwise.

We may limit the number of API calls we permit You to make during any given period.

Zurich reserves the right to take actions (e.g. limiting number of calls or the amount of data returned by each call) necessary to ensure performance of the API is not impacted by limiting the access for persistent misuse of the API. Extreme cases may result in revoking the key for that user. Examples of misuse include, but are not limited to:

• An API is not being used as intended – for example a RESTful web service being invoked continuously for the same data set, i.e. invoking the API more than once in a half hour period for data that is only updated on a half hourly basis
• Unauthorized use of an API key (e.g. using another user’s key).
• Use of the API to send content that does not comply with Zurich's Security Policy.

9. Support

Zurich will provide API documentation with details on how to use the API services and the process required to access the service. Zurich will ensure that the API is functional and has no obligation to provide support beyond providing the API credentials, completing account registration and granting access.

Zurich will not provide formal client side technical assistance in API integration or GTO Third Party Liability API configuration. Support details are provided in the Support section of the documentation and tickets can be raised via ServiceNow.

10. Service Level Agreement

The SLAs described here are not financially backed, i.e. no economic recompense will be offered for downtime exceeding the availability goals. For a calendar month, the Monthly Uptime Percentage goals are defined in the following table:

Monthly Uptime Percentage (excluding any maintenance windows)
Target 99.8%
Minimum 99.5%

The Monthly Uptime Percentage is calculated by subtracting from 100% the percentage of minutes during the month in which the API was not available. The SLA does not apply to any performance or availability issues:

• due to factors outside Zurich’s reasonable control
• resulted from Customer’s or third party hardware or software
• resulted from actions or inactions of Customer or third parties
• caused by Customer’s use of the API after Zurich advised Customer to modify its use of the API, if Customer did not modified its use as advised
• during beta and trial services (as determined by Zurich)

Changes to the SLAs will Zurich will provide at least 30 days’ notice for changes to the SLAs.

11. Term and Termination

The term will commence on the date upon which You agree to these Terms and will continue until terminated as set forth below.

You may stop using our APIs at any time with or without notice however charging will continue to apply to the next billing cycle. Further, if you want to terminate the Terms, you must provide Zurich with prior written notice and upon termination, cease your use of the applicable APIs.

Zurich may suspend or terminate the Customer’s use of the API at any time if we believe You have violated the API Terms.

Upon termination of these Terms, all rights and licenses granted to You will terminate immediately.

12. License fees and payment terms

Usage of the API is charged via an annual charge to your nominated cost centre. This charge will be applied 30 days after service commencement once the 30 day trial window has elapsed. If you notify Zurich GDP before the 30 day trial window has elapsed you can exit the service without charge. Zurich reserves the right to modify the fees for the future use of and/or continued access to the API in our sole discretion. We will provide at least 30 days' notice of any variation.

If you decide to terminate the service the service will remain available for you until the next annual cycle. Due to our need to pre-pay for the service we will not offer partial refunds.

If we do change the fee for use of the API or any tools and features, You do not have any obligation to continue to use Our resources.

13. Nondisclosure

You acknowledge and agree that Zurich considers the API access credentials and non-public information about the API and API Content disclosed to You to be confidential and proprietary information of Zurich (“Confidential Information”) which may not be disclosed to any third party, except contractors working on Your behalf who are subject to non-disclosure obligations that sufficiently protect such information, without the prior written consent of Zurich.