Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The following checklist describes the high level tasks that need to be completed in order to completely integrate the XCover API and begin selling insurance policies.
Obtain Sandbox access credentials from Cover Genius CSE (Client Solutions Engineer)
Test using Sandbox credentials
Obtain Test Production credentials from CSE
Deploy integration to Pre Production environment
Share Pre Production access details with CSE
CSE performs end-to-end testing in Pre Production and Cover Genius Compliance Manager signs off on integration
Fix any issues that arise
Final testing and sign-off carried out by CSE
Obtain Production credentials from CSE
Production deployment date scheduled with CSE
Deploy integration to Production environment
Start selling insurance policies
Event cancellation insurance or warranties - Offered via event or ticket booking platforms
Ticket and event sales services can present relevant cancellation insurance or ticket warranty policies in the event purchase booking path. Commonly, partners will integrate XCover using two key purchase process API calls: create quote and create booking. See a collection of common requests for this integration type, by contacting your CSE. Most integrations follow the below high level flow of events:
1. User browses event options and 2. Selects a event/ticket package 3. Partner platform sends a quote package payload to the create quote endpoint 4. User selects insurance options 5. User pays for tickets and insurance at checkout 6. Payment collection 7. Partner sends a booking request to the create booking endpoint 8. XCover sends confirmation email including policy details and partner sends purchase confirmation and tax invoice.
Modification - Only non financial modifications are applicable for this policy type.
Cancellation - Due to the nature of event/cancellation policies cancellations are restricted in line with relevant regulations.
In circumstances where a customer chooses to purchase tickets, but not the insurance offer. An opt-out request is used to notify XCover of a non-opted insurance quote. This assists with pricing and product offer data analysis and ultimately improved offers and sales results.
Property related insurance products such as Renters, Landlord, etc
Commonly, partners will integrate XCover using two key purchase process API calls: create quote and create booking. Most integrations follow the below high level flow of events:
1. User goes through a property related User Experience 2. Partner platform sends a quote package payload to the create quote endpoint 3. User selects insurance option/s 4. User pays for travel and insurance at checkout 5. Payment collection 6. Partner sends a booking request payload to the create booking endpoint 7. XCover sends confirmation email including policy details, Partner sends purchase confirmation and tax invoice.
Modification Changes to customer details such as name, address, or any rating factor needs to be captured in order to ensure the customer is paying the appropriate premium.
Cancellation Should a partner need to facilitate policy cancellation, the below workflow should be referenced.
In circumstances where a customer chooses to purchase the anchor product or service, but not the insurance offer. An opt-out request is used to notify XCover of a non-opted insurance quote. This assists with pricing and product offer data analysis and ultimately improved offers and sales results.
All HTTP requests sent to the XCover API must be signed with a special signature. The signature must be provided in the Authorization
header. In order to generate signature partners need to have a valid API key and a secret signing key. Please note, a new signature must be generated for every request.
XCover API uses HMAC-based authentication.
To authenticate API request the client application needs to perform the following steps:
Prepare request data for signing.
Sign data using one of the HMAC algorithms such as SHA1
(dprecated), SHA256
, SHA384
or SHA512
algorithms.
Encode the signature using Base64
encoding.
URL encode the result of the previous step.
Prepare Authorization
header containing the Base64 and URL encoded signature string, API Key and the algorithm used, for example hmac-sha512
.
Please note the date string to be signed should be in RFC 822 Section 5.1 format e.g. Thu, 04 Nov 2021 18:07:11 GMT
The date must be padded e.g. 04.
Please note the signature must be a base64 encoded strictly matching RFC 4648. Some programming languages will URL safe base64 encode which will replace the "+" and "/" characters with "-" and "_" respectively. This will cause a "Signature string does not match!" error.
Below you can see an example code implementing these steps, this code can be used as a pre-request script in Postman.
XCover API offers provides access to staging environment that can be used to test the platform during the integration. To access the sandbox environment partners need to use testing API key that is provided by XCover team.
Outline of some frequently implemented approaches for specific industries
XCover enables in context sale of insurance to multiple industry verticals. Generally, purchase of goods and services and insurance follows a linear path: 1. Product or service selected by consumer 2. Insurance quote generated and presented to user 3. Insurance is selected and attached to the main product 4. Payment is received and then the insurance booking is confirmed with XCover The following common use cases explain in more detail how this process operates.
By default, the following base API rate limits apply for all partner API keys:
Fast quote endpoint: 50 req/sec
All other endpoints: 10 req/sec (shared across all endpoints)
All testing API keys: 2 req/sec
Please, reach out to the Account Manager or Client Solution Engineer if you want to increase these limits.
Product Insurance or Warranties
Retail platforms and marketplaces can seamlessly present relevant warranty and insurance policies in the purchase path. Commonly, partners will integrate XCover using two key purchase process API calls: create quote and create booking. Depending where the offer of insurance is provided (at product page, cart page, or between as a product is added to cart), a single product quote or package quote can be used. See a collection of common requests for this integration type Most integrations follow the below high-level flow of events:
1. User browses product options and; 2. Selects a product to cart (or arrives at a product page etc.) 3. Partner platform sends a quote package payload to the create quote endpoint 4. User selects insurance option/s 5. User pays for product/s and insurance at checkout 6. Payment collection 7. Partner sends a booking request to the create booking endpoint 8. XCover sends confirmation email including policy details, Partner sends purchase confirmation and tax invoice.
In-Store CG Portal Process
For in-store purchases, sales associates can utilize the Cover Genius Portal on an iPad or similar device. The online form requires a few details about the product and some customer and payment information to protect a customer's purchase(s).
Cancellation Should a partner need to facilitate policy cancellation (for example, a product return, or order cancellation), the below workflow should be referenced.
In circumstances where a customer chooses to purchase products, but not the insurance offer. An opt-out request is used to notify XCover of a non-opted insurance quote. This assists with pricing and product offer data analysis and ultimately improved offers and sales results.
Idempotency keys are unique identifiers that API clients can provide in HTTP request headers to ensure that a specific API request is not processed multiple times even if it is accidentally sent more than once. This mechanism helps maintain data consistency and prevent undesired side effects like duplicated transactions or repeating customer notifications.
Idempotency keys can be passed to most of the non-idempotent endpoints through a custom header x-idempotency-key
. The value of this header should be a unique operation identifier. If the request with the same idempotency key and body has already been processed in the past the response body will be stored in a temporary storage for 48 hours and returned to all subsequent requests with 409 Conflict
status code. The 409 responses can be handled by the API client as if it would be a successful response. The use of a separate response code can help API consumers identify the root cause for duplicated requests and fix the issue.
In some cases when two duplicated requests are sent within a short interval of time it is possible that a 423 Locked
response code will be returned. The 423 response indicates that the API started processing the previous request, but the response was not generated yet. The API client should retry the request after a reasonable amount of time.
Find below an example of code that illustrates implementing the idempotency keys mechanism using Python's requests
library.
How will customers pay for their policy premium?
Most XCover partners operate their own shopping cart, checkout, and payment collection processes. From a customer experience perspective, a single itemised purchase transaction is preferable (for example a travel booking along with the insurance policy).
Please refer to the Single Payment page for more information.
In rare circumstances, Partners and XCover may agree to operate a dual payment integration approach. This results in two transactions against the same payment method of the user in quick succession. The merchant of record for the product/service remains the Partner, and the merchant of record for Insurance remains XCover. If this is your preferred integration method, please speak to your Partnerships manager or Client Solutions Engineer.
Please refer to the Dual Payment page for details on implementing this workflow.
In some circumstances, Partners may choose to integrate split payments (by using an approved payment provider) to split the transaction after payment collection, ie. One payment, two merchants (Partner and XCover), and two settlements (Partner and XCover). If this is your preferred integration method, please speak to your Partnerships manager or Client Solutions Engineer.
Sending a Quote Request
The Quote request details the required information of this attached main product so that an appropriate policy quotation can be generated. The response from the Quote endpoint can be used to display information about the policy which includes:
Policy Reference ID - Unique 13 letter code for each policy (id
eg. TXLDR-LH8UN-INS
)
Policy Price and Applicable Taxes
Product Disclosure Statement
Legal Disclaimer
Inclusions/Exclusions
Certificate of Insurance (COI)
Benefits, Limits and Excess
Cover Amount
Making a POST
request to the quotes
endpoint returns one or several insurance products based on the request. The request to the quotes
endpoint is a list (as shown below). At the top level of the request, include the common fields for the quotes like currency
, customer_country
, customer_language
.
Every Quote request should have the minimum required information to get a quote for the specific Product. For instance, in the case of Product Insurance - we need the category, price, name, description.
The response has the insurance price and details about the policy in the requested currency for the supplied parameters. This information can be presented to the customer to move them to the Booking stage.
The response has a top-level ID that is identified by a unique 13 letter alpha-numeric string ending with -INS
suffix. There's also an individual ID assigned to each individual quote in the request. Both of these can be stored on the clients side to to cancel, modify and renew the policies during its lifecycle.
The initial status after the Quote Request is RECEIVED
For some integrations quote step can be skipped or quote responses can be cached, but we encourage all partners to implement price request via quote endpoint in order to enable dynamic product optimisations provided by BrightWrite platform.
An example of quote request can be found below.
POST
https://api.xcover.com/x/partners/:partner_id/quotes/
This API call will retrieve the most relevant policies available for distribution
partner_id
string
Unique Partner Code
Content-Type
string
application/json
Date
string
Current Datetime
Authorization
string
HMAC Signature
X-Api-Key
string
API Key
In the request body, you can send multiple quote requests. This means that in the case of a 201, you will get back a quote for each request. You only need to make one API call to get many quotes. The next example demonstrates this.
POST
https://api.xcover.com/x/partners/:partner_id/quotes/
An example of requesting a QuotePackage with two policies for two separate products. The first element of the Request array is a Policy for a Laptop followed by a Mobile phone policy
The response under quotes
key in the body is zero-indexed based on the position in the request. The first element has an index of 0
in the response, the second element has an index of 1
and so on.
partner_id
string
Unique Partner Code
Content-Type
string
application/json
Date
string
Current Datetime
Authorization
string
HMAC Signature
X-Api-Key
string
API Key
When you request a quote, we send you back a quote package ID (INS number) in the response body, which can be used to retrieve information about all the quotes in the quote package. This is useful incase you don't want to store the Quote response on your side.
GET
https://api.xcover.com/x/partners/:partner_id/quotes/:quote_package_id
The Quote Package ID is obtained during the Quote Request
partner_id
string
Unique Partner Code
quote_package_id
string
Quote Package ID
Content-Type
string
application/json
Date
string
Current Datetime
Authorization
string
HMAC Signature
X-Api-Key
string
API Key
PATCH
https://api.xcover.com/x/partners/{partner_id}/quotes/{quote_package_id}/
Use this endpoint to mutate an existing Quote in a Quote Package.
partner_id
string
Unique Partner Code
quote_package_id
string
Quote Package ID
Content-Type
string
application/json
Date
string
Current Datetime
Authorization
string
HMAC Signature
X-Api_Key
string
API Key
POST
https://api.xcover.com/x/partners/{partner_id}/quotes/{quote_package_id}/
The add
endpoint can be used with an already generated INS
(quote-package-id) to add new Quotes to an existing policy. For example: If the customer adds another Phone protection to their existing Product insurance policies, you could use this endpoint to add a new Quote to an existing Quote Package.
partner_id
string
Unique Partner Code
quote_package_id
string
Quote Package ID
Content-Type
string
application/json
Date
string
Current Datetime
Authorization
string
HMAC Signature
X-Api_Key
string
API Key
The add
method can only be used for Quotes in the RECEIEVED
status.
POST
https://api.xcover.com/x/partners/{partner_id}/quotes/{quote_package_id}/
The add
endpoint can be used with an already generated INS
(quote-package-id) to delete a specific policy, we need the ID of the Quote from the original request. Simply putting that id
in the request will delete the right policy. For example: If the customer remove a product with protection from their cart.
partner_id
string
Unique Partner Code
quote_package_id
string
Quote Package ID
Content-Type
string
application/json
Date
string
Current Datetime
Authorization
string
HMAC Signature
X-Api_Key
string
API Key
The remove
method can only be used for Quotes in the RECEIEVED
status.
Sending a Fast Quote Request
The Fast Quote endpoint is available to partners who meet specific criteria outlined by Cover Genius. Please contact your assigned Client Solutions Engineer (CSE) to discuss use of the Fast Quote endpoint.
Fast Quote request is commonly issued at product pages to display selective information about the policy which could include:
Policy Price
Product Disclosure Statement
Legal Disclaimer
Inclusions/Exclusions
Making a POST
request to the fast quotes
endpoint returns one or several insurance products based on the request. The request to the fast quotes
endpoint is a list (as shown below). At the top level of the request, include the common fields for the quotes like currency
, customer_country
, customer_language
along with boolean field fast quote
set as true.
Every Fast Quote request should have the minimum required information to get a quote for the specific Product. For instance, in the case of Product Insurance - we need the item category, price, name, description.
The response could have the policy details, static PDS and the price in the requested currency for the supplied parameters. This information can be presented to the customer to move them to the Booking stage.
Fast Quote is followed by Instant Booking as the next stage in the user journey where insurance is selected.
An example of fast quote request can be found below.
POST
https://api.xcover.com/x/partners/:partner_id/quotes/?fast_quote=1
This API call will retrieve the most relevant policies available for distribution
partner_id
string
Unique Partner Code
fast_quote
boolean
true
Content-Type
string
application/json
Date
string
Current Datetime
Authorization
string
HMAC Signature
X-Api-Key
string
API Key
In the request body, you can send multiple quote requests. This means that in the case of a 200ok, you will get back a quote for each request. You only need to make one API call to get many quotes.
The XCover platform enables efficient, flexible, and compliant offer and sale of any line of insurance within a partner web experience.
Some examples include:
- A public facing Online Travel Agent selling flight and accomodation packages, with related travel and cancellation insurance.
- A merchant facing shipping management platform selling parcel and shipping insurance.
- An ecommerce retail marketplace facilitating sales and offering warranties and or insurance policies for relevant products.
In most integrations XCover policies are attached to one or more main products or services.
An example of main product is a laptop purchased from an online store, flight tickets, hotel reservations, etc.
Depending on the partner integration, the insurance offering is typically placed in the main product booking path.
Common Request Flow:
1. Quote
The initial status after the Quote Request is RECEIVED
2. Booking
After customers complete the booking process and insurance premiums are collected by the partner a request to the booking endpoint must be made.
A CONFIRMED
INS is considered booked, sold, provisioned, and will result in a policy confirmation being submitted to the user.
A simple example of such integration is demonstrated below.
Total Shipping Insurance - Offered to Merchants or Consumers
Shipping services and platforms offering parcel shipping, or marketplaces connected to 3rd party logistics services (3PL's) can enable the offer and or attachment of parcel insurance policies in the purchase path. Commonly, partners will integrate XCover using two key purchase process API calls: create quote and create booking. See a collection of common requests for this integration type. Many integrations follow the below high level flow of events:
1. User creates a shipment order 3. Partner platform sends a quote package payload to the create quote endpoint 4. User selects insurance option/s 5. User pays for shipment and insurance - this is often a debit of merchants shipping account wallet 6. Partner sends a booking request payload to the create booking endpoint 7. Confirmation of the coverage is presented to the user
Cancellation In the event that a shipment label is not collected, and rendered void by the platform (within appropriate timeframes) the policy booking may be cancelled.
Travel Insurance such as Comprehensive, Medical, Baggage, Cancellation, Smart Delay, Insolvency, and more - Offered via Online Travel Agents and other platforms.
Online Travel Agents (OTA's) and Accommodation platforms selling flights, hotel bookings, experiences and travel packages can seamlessly present relevant travel insurance policies in the purchase booking path. Commonly, partners will integrate XCover using two key purchase process API calls: create quote and create booking. See a collection of common requests for this integration type Most integrations follow the below high level flow of events:
1. User browses travel options and; 2. Selects a travel offer 3. Partner platform sends a quote package payload to the create quote endpoint 4. User selects insurance option/s 5. User pays for travel and insurance at checkout 6. Payment collection 7. Partner sends a booking request payload to the create booking endpoint 8. XCover sends confirmation email including policy details, Partner sends purchase confirmation and tax invoice.
Modification Where a partner operates a management service for booked travel services, modifications to policies may be submitted to adjust for trip length (financial adjustment), or basic updates such as address changes for a policy profile (non-financial adjustment)
Cancellation Should a partner need to facilitate travel and policy cancellation (note that this differs from trip cancellation policies, which due to their nature, may not be cancelled), the below workflow should be referenced.
In circumstances where a customer chooses to purchase travel, but not the insurance offer. An opt-out request is used to notify XCover of a non-opted insurance quote. This assists with pricing and product offer data analysis and ultimately improved offers and sales results.
Using XCover elements, the work of coding to display quote response is removed.
A simple script is used as a wrapper for the quote request
If custom display settings are required, they may be applied using signals or taken from quote request variables (see below example).
Using Content Delivery Network (CDN), offers are displayed within the purchase flow on partner site.
Response Signals are used to determine user interaction/purchase choices.
This approach reduces the up front development effort and any ongoing growth project maintenance, allowing for streamlined launch and optimizations See more documentation for XCover Elements panel display here
Important: Most display variations are handled by quote request attributes for example the currency display could be set as Indonesian Rp (IDR):
In some cases, partners may have custom display requirements based on experience settings or customisations. An examples of custom display settings is shown below:
In the above example, circled (blue) formatting for currency symbol is selected using custom set signals (symbol). Eg:
In the below example, the currencyDisplay config element is set to narrowSymbol
Overview of the payment process where the partner is the Merchant of Record (MoR)
Partners operating in markets that allow the collection of insurance premiums by non-insurance companies may use this method of premium collection. This is the most common approach for XCover partner integrations, and offers significant efficiency, process, and approval rate benefits.
If you are planning to sell insurance products to residents of the United States of America then it is likely the integration would use the unless the insurance products are travel or warranty related, in which case you might be eligible for a Travel Retailers or general warranty exemption. Please contact your assigned Client Solutions Engineer (CSE) for more information.
For partners planning to sell insurance products solely to residents of the Europe Union you might be eligible to become an Approved Representative of Cover Genius allowing you to collect premium. Otherwise you must use the . Please contact your assigned CSE for more information.
For partners planning to sell insurance products to residents elsewhere please contact your assigned CSE for more information on how to collect premiums if you wish to remain the Merchant of Record.
Optionally, Partners may choose to track the payment/checkout item using meta-data fields as indicated below, in the booking or instant booking request:
No integration steps are required for a single payment implementation approach
Presenting the Insurance/Protection offer in the purchase path
Partners will often present an insurance offer after customers have selected a core product (such as a laptop, travel booking, event tickets, etc.). There are key components to presenting an insurance/protection offer, where 1-3 are dynamic from API response, and the items under 4 are static (provided or approved by Cover Genius CSE):
Price
Disclaimer
Policy wording link
Product name, inclusions, panel content, Trustpilot banner, and graphical elements.
Cover Genius offers a standard or customised design structure optimised for the partner specific use case (ie. Travel, Parcel, Ticket, Retail, etc.). A Travel example is presented below:
Legend: Red = Static content , Blue = API response
A Trustpilot.com rating for XCover, demonstrates reliability
B Inclusions content, taken from XCover supplied content
API Response content:
1. Price, per ticket (division of "total_price"
by number of travellers/units) or full price if in "add" button ("total_price"
)
2. Disclaimer, taken from "content":{ "disclaimer"}
field
Generally, the quote display should address:
Customer relevance - Does the quote/product presentation make sense for this purchase flow?
Compliance and regulatory requirements - Does the offer meet requirements for disclaimers, price, statements of fact, and availability of policy wording?
Marketing copy and trust - Is the offer likely to be understood and selected by the customer? Is the offer trusted/compelling?
Booking process overview
The Booking endpoint is used to confirm the purchase of the insurance offering.
If a customer has chosen to purchase the insurance product(s) offered in the previous Quote step the customer must complete the checkout process with payment being successfully collected before proceeding with the following steps to confirm and distribute the policy.
After customers complete the booking process and insurance premiums are collected by the partner a request to the booking endpoint must be made.
Validations:
1. Given the initial status after the Quote Request is RECEIVED
, when a booking request is submitted, the expected status returned in response payload after a successful booking request is CONFIRMED
.
2. The price field should also be validated, to confirm the final price matches the quote stage price.
3. The presence of an "errors" object in response payload indicates an important logic error in booking, that should be noted.
A CONFIRMED
INS is considered booked, sold, provisioned, and will result in a policy confirmation being submitted to the user.
POST
https://api.xcover.com/x/partners/:partner_id/bookings/:quote_package_id
The booking endpoint accepts a JSON payload against the URI containing the quote package ID returned in the quote request. The payload consists of policyholder information (most likely the same as the customer) and a list of quotes selected for purchase. the most relevant policies available for distribution
The Instant Booking endpoint is available to partners who meet strict criteria outlined by Cover Genius. Please contact your assigned Client Solutions Engineer (CSE) to discuss use of the Instant Booking endpoint.
If a customer has chosen to purchase the insurance product(s) offered through your platform then a call to the Instant Booking endpoint should be issued after the insurance premium has been calculated and payment has been captured.
POST
https://api.xcover.com/x/partners/:partner_id/instant_booking/
The payload consists of information necessary to issue the policy (widely varying depending on policy type) and policyholder information
The Insurance opt-out workflow describes the API call that must be made in the case that XCover insurance is offered but not selected by the customer. The purpose of utilising the opt-out workflow is so Cover Genius can demonstrate conversion rate to the regulators ensuring the product and pricing is fit for purpose. It also enables XCover machine learning platform Brightwrite to deliver the optimal products at the optimal prices.
POST
https://api.xcover.com/x/partners/:partner_id/bookings/:quote_package_id/opt_out
The opt-out request does not require any data to be contained in the payload.
Modifying an existing booked policy
The modification workflow is used when a customer wants to make a change to their existing policy. Examples could include; changing the date of an overseas vacation, increasing the item value or value of goods in a container, or changing the date of an event.
These changes may be possible for certain policies and can be done using the Booking Update API endpoints. These changes, if available, will cause a difference in policy price which may result in a refund or additional fee depending on the changes made.
The below diagram illustrates the API calls needed to successfully modify a customers policy.
The first step is to obtain information regarding the customers purchased insurance, this step can be skipped if you have stored all relevant information about a customers insurance booking such as INS number, Quote IDs, price paid, etc.
GET
https://api.xcover.com/x/partners/:partner_id/bookings/:quote_package_id
Retrieves a specific booking by providing the quote package ID.
In some circumstances a modification will not impact the premium price of a specific policy. This could be for a variety of reasons where additional information is supplied to enhance the profile of a policy, covered item, or insured party. Examples of such use cases: - Manufacturer or serial number information received after the policy booking - Product receipt or ownership verification documents or images - Address or phone number information updates for the insured
Ensure the fields you are modifying do not affect price. Speak to your assigned Client Solutions Engineer (CSE) before implementing this endpoint.
PATCH
https://api.xcover.com/x/partners/:partner_id/bookings/:quote_package_id/
Updates booking details instantly.
A request to the quote_for_booking_update endpoint will include the details of the policy that have changed the response will include the outstanding amount to be charged or refunded.
After calling the quote_for_booking_update endpoint, and once partial refund or any additional charge is collected, a confirm update request is submitted to complete the booking update workflow.
PATCH
https://api.xcover.com/x/partners/:partner_id/bookings/:quote_package_id/quote_for_update
Generates a Quote for booking changes as specified in the request which can then be confirmed using the endpoint specified in the Response
A reduction in ticket prices here is used as an example for a cause for policy value refund. See response in above section tab.
To confirm a modification that has been previewed a request to the following endpoint needs to be made.
POST
https://api.xcover.com/x/partners/:partner_id/bookings/:quote_package_id/confirm_update/:update_id/
Confirm the booking update and charge or refund. Optionally include the charge ID reference. Request contains no payload.
Overview of the dual payment process where Cover Genius is the Merchant of Record
Partners that are at a minimum of PCI DSS SAQ A compliant are able to utilise the XPay API to process the insurance transaction. This will make Cover Genius the Merchant of Record (MoR).
After a customer selects the insurance product and proceeds to the checkout stage, the payment information (credit card details) must be collected and transmitted through the customer tokens endpoint.
The XPay API uses a long lived JSON Web Token (JWT) which will be provided to you by the assigned Client Solutions Engineer (CSE).
POST
https://api.xpay.xcover.com/customer-tokens
This API call will tokenize the customers credit card details.
Note, the /cutomer-tokens endpoint will not charge the customer, just tokenise their payment details. The customer is charged on the subsequent /bookings API call.
After a successful response from the customer tokens endpoint, the partner must confirm the booking by sending a request to the booking endpoint with the customer_token_id
set to the id
from the previous step, this will charge the customer.
POST
https://api.xcover.com/x/partners/:partner_id/bookings/:quote_package_id
This API call will retrieve the most relevant policies available for distribution
Once payment has been finalised policy documents, certificate of insurance will then be issued to the customer.
Cancel a specific policy booking
Cancelling a policy booking is used where a user no longer requires coverage, and has contacted the partner directly to cancel this policy.
For example: Cancellation of a Product insurance policy where the product is on-sold or no longer needed. Where a refund is due, the partner (depending on method of payment collection, and policy cooling off period) may need to provide a refund to the user. This calculated pro-rata refund for the user (where applicable) is returned in the Cancellation response.
The first step is to obtain information regarding the customers purchased insurance, this step can be skipped if you have stored all relevant information about a customers insurance booking such as INS number, Quote IDs, price paid, etc.
GET
https://api.xcover.com/x/partners/:partner_id/bookings/:quote_package_id
Retrieves a specific booking by providing the quote package ID.
Once a booking has been retrieved, check the can_be_cancelled
flag is set to true
in the response before issuing a cancellation request.
To ensure you refund the correct amount to the customer, it is recommended to first preview a cancellation and then confirm the cancellation once you have successfully issued the refund.
POST
https://api.xcover.com/x/partners/:partner_id/bookings/:quote_package_id/cancel
The booking cancel endpoint accepts a JSON payload against the URI containing the Quote Package ID returned by a /booking
request. The payload consists of a list of quotes selected for cancellation and an optional reason for the cancellation.
An optional preview
flag can be set to true in the booking cancellation request payload, the response will confirm a refund amount and timeframe required before cancellation can be completed.
It is important to note key details in the response, including thecancellation_id
,total_refund
amount and theconfirm_before
datetime
POST
https://api.xcover.com/x/partners/:partner_id/bookings/:quote_package_id/cancel
The booking cancel endpoint accepts a JSON payload against the URI containing the Quote Package ID returned by a /booking
request. The payload consists of a the preview
flag set to true along with a list of quotes selected for cancellation and an optional reason for the cancellation.
To confirm a cancellation that has been previewed a request to the following endpoint needs to be made.
POST
https://api.xcover.com/x/partners/:partner_id/bookings/:quote_package_id/confirm_cancellation
Confirm the previewed cancellation.
3. Policy Wording, taken from the "pds_url"
quote response field, for example: "view wording" as a hyperlink of: "ABCD-1234-INS"
partner_id
string
Unique Partner Code
quote_package_id
string
Quote Package ID
Content-Type
string
application/json
Date
string
Current Datetime
Authorization
string
HMAC Signature
X-Api-Key
string
API Key
partner_id
string
Unique Partner Code
Content-Type
string
application/json
Date
string
Current Datetime
Authorization
string
HMAC Signature
X-Api-Key
string
API Key
partner_id
string
Uniquer Partner Code
quote_package_id
string
Quote Package ID
Date
string
Current Datetime
Authorization
string
HMAC Signature
X-Api-Key
string
API Key
partner_id
string
Unique Partner Code
quote_package_id
string
Quote Package ID (INS)
Content-Type
string
application/json
Date
string
Current Datetime
Authorization
string
HMAC Signature
X-Api-Key
string
API Key
partner_id
string
Unique Partner Code
quote_package_id
string
Quote Package ID (INS)
Content-Type
string
application/json
Date
string
Current Datetime
Authorization
string
HMAC Signature
X-API-Key
string
API Key
partner_id
string
Unique Partner Code
quote_package_id
string
Quote Package ID (INS)
Content-Type
string
application/json
Date
string
Current Datetime
Authorization
string
HMAC Signature
X-API-Key
string
API Key
partner_id
string
Unique Partner ID
quote_package_id
string
Quote Package ID (INS)
update_id
string
ID referencing the update
Content-Type
string
application/json
Date
string
Current Datetime
Authorization
string
HMAC Signature
X-API-Key
string
API Key
Content-Type
string
application/json
Authorization
string
Bearer {{JWT}}
partner_id
string
Unique Partner Code
quote_package_id
string
Quote Package ID
Content-Type
string
application/json
Date
string
Current Datetime
Authorization
string
HMAC Signature
X-Api-Key
string
API Key
partner_id
string
Unique Partner Code
quote_package_id
string
Quote Package ID (INS)
Content-Type
string
application/json
Date
string
Current Datetime
Authorization
string
HMAC Signature
X-Api-Key
string
API Key
partner_id
string
Unique Partner Code
quote_package_id
string
Quote Package ID
Content-Type
string
application/json
Date
string
Current Datetime
Authorization
string
HMAC Signature
X-Api-Key
string
API Key
partner_id
string
Unique Partner Code
quote_package_id
string
Quote Package ID
Content-Type
string
application/json
Date
string
Current Datetime
Authorization
string
HMAC Signature
X-Api-Key
string
API Key
partner_id
string
Unique Parter Code
quote_package_id
string
Quote Package ID
cancellation_id
string
Cancellation ID
Content-Type
string
application/json
Date
string
Current Datetime
Authorization
string
HMAC Signature
X-Api-Key
string
API Key
XCover enables the world’s largest ecommerce companies to protect all of their customers.
The XCover platform includes an easy-to-use API integration to promote, sell, and manage insurance products provided by Cover Genius underwriting partners. It is designed to seamlessly integrate with any ecommerce platform and sell any line of insurance products.
This is made possible by the XCover API, a flexible interface based on REST that returns standard HTTP response codes and JSON-encoded responses.
Please, follow us on LinkedIn for the latest updates.
This outline is intended to provide an overview of the integration workflows for anyone working with an XCover API integration, including (but not limited to): Product & Project Managers, Software Engineers, and Business Analysts.
It demonstrates an example XCover distribution partner with a typical online store.
The store uses XCover API to quote for insurance prices for the product insurance policies and offers to their customer to purchase ancillary insurance products along with the main products. Customers can add the insurance product to their shopping cart and continue to checkout. Alternatively, they can opt-out from the insurance offering and proceed to checkout with the main product only.
After successful checkout, the store calls XCover API to notify about the policies purchased and provides the policyholder information. XCover API will inform customers about all the insurance product features, offer to create an account on to the XCover.com website where they can modify, renew, cancel the purchased policies, or lodge a claim. XCover takes care of registering the purchased policies with the underwriting partners as well.
If booking Modifications are allowed by the underwriting partner XCover allows booking modification by customers via XCover.com. Alternatively, booking modifications can be triggered by one of the partner's platforms via XCover API.
It can happen that the customer is not happy with the product purchased and wants to return it. XCover API offers cancellation workflows that allow the previously issued policy to be canceled and refunded automatically in this case.
XCover.com also offers automatic renewals when it is required by the integration.
Customers can always send a claim via XCover.com in case if one of the conditions under the policy is triggered. XCover offers highly automated and fast quote assessments and payouts via its XClaim and XPay internal APIs.
How are users able to view and understand policy details, and initiate claims?
Due to their regulated nature, claims are solely handled by Cover Genius. Cover Genius is responsible for all communications with users, claims assessment and claims payments. Users can lodge the claim on XCover.com/claims by completing an online, pre-filled form, provide a description of the situation/event and provide any supporting information or documents required. Generally, in situations where customers contact your platform in regards to claims, they should be redirected to XCover.com.
Users will need to submit a first notice of loss form (FNOL) in order for claims to be assessed. Generally, this is completed by a logged in user at XCover.com/claims.
Claims will be assessed by Cover Genius via our in-house claims assessment system. We leverage our technology and existing policy data to provide efficient and automated approval process, and fast electronic claims payment.
Medical assistance and medical-related claims may be handled by our underwriting partners directly. Cover Genius works with our underwriters to create a user-centric workflow to ensure a smooth process relevant to your use case.
Generally, claims are solely managed by Cover Genius. If you wish to discuss integrating claims submission into your experience, please contact your partnership manager.
Most users will manage policies on XCover.com
After booking and over the course of using a policy, users may need to manage their policy, to view and reference their policy inclusions, limits, or terms and conditions, and to update their account information. In most instances, this is performed on XCover.com Partners may wish to include a link to this page in their experience, and often a specific policy URL will be appropriate to include, such as: Claims: https://xcover.com/en/account/claims/fnol?bookingID=1ABCD-VWXYZ-INS Modification: https://xcover.com/en/modify/1ABCD-VWXYZ-INS Certificate of Insurance (COI): https://xcover.com/en/coi/1ABCD-VWXYZ-INS Policy Disclosure Statement / Policy Wording (PDS): https://xcover.com/en/pds/1ABCD-VWXYZ-INS Users will also need to have created an account before using these links. In most cases, users will receive an account creation email containing a specific login URL shared with them after booking, usually via a policy confirmation email.
A XCover Quote Package and individual Quotes within a Quote Package can transition between several different statuses. The below is a state diagram of these transitions and their conditions.
For certain policy types (eg. Warranty/Product Insurance/Renters) a renewal period may be established for ongoing protection. Eg. A laptop warranty with an annual renewal cycle. Or a renters insurance product
Before the policy end date the customer should be sent a notification that their policy is expiring and will be (auto) renewed (depending on their settings in your platform).
An example of the renewal workflow is illustrated below.
PATCH
https://api.xcover.com/x/partners/:partner_id/renewals/:quote_package_id/quote_for_renewal/
Generates an updated booking with a renewal price that should be charged to the customer. It also contains any other changes to benefits/limits or policy wording that may have changed since the first policy was purchased. Request contains no payload.
partner_id
string
Unique Partner Code
quote_package_id
string
Quote Package ID (INS)
Content-Type
string
application/json
Date
string
Current Datetime
Authorization
string
HMAC Signature
X-API-Key
string
API Key
To confirm a renewal once payment has been collected a request to the following endpoint needs to be made.
POST
https://api.xcover.com/x/partners/:partner_id/renewals/:quote_package_id/confirm/:renewal_id/
Confirms the renewal and issues the updated policy to the customer.
partner_id
string
Unique Partner ID
quote_package_id
string
Quote Package ID (INS)
renewal_id
string
ID referencing the renewal
Content-Type
string
application/json
Date
string
Current Datetime
Authorization
string
HMAC Signature
X-API-Key
string
API Key
id*
String
The policy quote requires updating.
policy_start_date*
String
The new policy start date
This feature allows customers to pay for an insurance product that covers them for a period of time (annually) in instalments instead of up-front.
The above diagram illustrates the API calls and webhook events made in order to record the payment of each instalment.
When a quote request is made for a policy that allows payment to be made in instalments an instalment_plans
property will be returned in the API response.
The amount to surface to the customer is reflected in the first_instalment_amount
attribute.
The instalment plan can be selected by provide the desired instalment name in the instalment_plan
attribute during a booking request.
Depending on the payment services provider a periodic payment will generate a webhook event. This event should be processed by your platform and the following API calls should be made to the instalments endpoint.
In order to record an instalment the correct instalment_id
needs to be provided. The next scheduled instalment_id
can be obtained by performing a GET request against the instalment endpoint.
GET
https://api.xcover.com/x/partners/:partner_id/bookings/:quote_package_id/instalments/
Returns instalment details including the payment schedule.
partner_id
string
Unique Partner ID
quote_package_id
string
Quote Package ID (INS)
Content-Type
string
application/json
Date
string
Current Datetime
Authorization
string
HMAC Signature
X-API-Key
string
API Key
To confirm the instalment once a payment attempt has been made a request to the following endpoint needs to be made containing the instalment_id
from the previous step.
POST
https://api.xcover.com/x/partners/:partner_id/bookings/:quote_package_id/instalments/
Confirms the instalment providing whether the payment was successful or not.
partner_id
string
Unique Partner ID
quote_package_id
string
Quote Package ID (INS)
Content-Type
string
application/json
Date
string
Current Datetime
Authorization
string
HMAC Signature
X-API-Key
string
API Key
An XCover Quote Package and individual Quotes within a Quote Package can transition between several different statuses. Below is a state diagram of these transitions and their conditions.
The XCover API operates with a set number of states that a quote can rest in.
RECEIVED: Refers to an initial quote creation state - this is not a live policy, but may be booked from this state.
CONFIRMED: A booked policy, this policy is confirmed as being paid for and activated. It may be active or expired. May be cancellable or modifiable, and can be claimed against.
CANCELLED: A cancelled policy cannot be claimed against, or modified.
DELETED: A rare status that depicts a removed quote/booking.
PENDING_PAYMENT: Only relevant for quotes that are booked using the require_payment_confirmation
flag during a create booking
request (usually followed by the confirm booking
request) end state if confirmed will be CONFIRMED.
FAILED: A failed quote status.
RENEWED: A state used to depict a renewed prior booked policy (for example after an annual renewal payment is confirmed).
General error management
Error Handling
XCover uses conventional HTTP response codes to indicate the success or failure of an API request. Error codes ranging from 400 to 499 represent various error codes. Errors that can be resolved programmatically will result in an error code that briefly explains the type of error or reason for the error. In the unlikely event of a 5xx error, our engineering team will automatically receive a report and will fix any issue as fast as possible.
Note the below workflow for error handling:
XCover strongly recommends the following mechanisms for error handling:
Retry Mechanism
The request/response goes through various hops between Partners and XCover. These may include various networks and servers. If at any point, the request fails due to network issue for example (e.g. a timeout), Partners should try to resend the request at least twice to rule out any intermittent issue. For Asynchronous request situations, retries may be spaced comfortably, ideally 2-5 mins apart before sending out an alert for someone to manually check any issues. We recommend at least 5 second timeout for bookings, and setting it to 10 seconds or more should be more reliable and not be a problem for customers. If requests fail, they should be retried with exponential backoff. In case the booking creation failed 5 times, partners should flag and raise with Cover Genius. Similar logic should apply for cancellations.
Alert Mechanism
If, after the second try Partners fail to receive the expected response (received, confirmed etc), it is recommended to establish alert mechanisms that notify responsible teams of the failure.
Logging Mechanism
Irrespective of a correct or a failed request/response, it is highly recommended for Partners to log requests and responses all centrally. These assist investigation where besides direct issue itself, patterns may become visible, helping to identify overarching issues.
The API adheres to the REST principles and provides developers-friendly, predictive and logically organised resource-oriented structure.
XCover API accepts date
and date-time
parameters in the format as defined by , for example 2018-01-01
, 2018-01-01T17:00:01Z
, 2018-01-01T17:00:00+01:00
, 2018-01-01T17:00:01.04399-04:00
. We encourage partners to keep the original timezone in contrast to sending all dates in UTC. Having original timezone can helps XCover to deal with potential issues with DST changes.
All country codes provided in API requests must be compliant with standard.
Currency must be compliant with 3-letter codes as defined by .
Language input must be compliant with 2-letter codes as defined but standard. Variations of base languages use a variant indicator, for example: "en-us" to specify english, united states variant (where applicable).
Phone numbers provided (at booking stage) should predominantly be of personal mobile/cell type, with the format of +[country_code]
plus a phone number, e.g.,
In some use cases, XCover will validate the phone number format (to allow sending SMS policy and claim communications to the customer), and return an error if an invalid format is provided.
Error type and management
(Stated in headers): , global environment based Basic approach: “Does the API respond with a 20X response?” Useful for: - General API function - Confirmation of actions - Basic operation validation
Example of use: - Was a quote request received? - Was a booking request received? - Was there any full failures
Logic errors are present in API response body, are case by case, and policy based.
They are often the indicator of a problem with the booking or quote, and may represent a partial booking failure. Always look for the "errors
" array.
Basic approach:
“Does the request contain any content concerns, or logical failures?”
Useful for:
- Calculation issues
- Confirmation over various state actions
(does a booking match a quote expectation)
- In depth rule validation
Example of use:
- Was a quote request valid?
- Was a booking request complete, were there any partial failures?
Logic error management:
All quotes in a quote or booking request should be confirmed individually (not just package, or package status). An erroneous quote will return a "null" response for the object. Example:
Booking request items should be confirmed similarly Example, basic elements present, first quote id sent also present
Booking request shouldn't have errors, mismatched values, or null quote responses
In the below example, the booking was successful, but partially failed due to a component quote having a logic error.
A null quote component will result in a differing value for the policy bundle, even in a confirmed state.
Understanding and monitoring for these response variations and errors will greatly reduce misalinged bookings and improve customer satisfaction.
How to add Cover Genius domains to your Apple Private Relay Email Sources
Due to the regulated nature of insurance customers must receive email communication about their coverage from the licensed entity distributing the insurance.
Usually, customers will receive these emails from our brands rentalcover.com, xcover.com and sweetly.com with no issues. The advent of new and convenient sign-up/in methods such as "Sign in with Apple" allows users to use an anonymous email address. When a user provides such an address to your app or website, the private relay email service routes all emails between you and the user. A private relay email service sends email to a recipient using an automatically generated email address. This hides the real email address to preserve privacy.
By default, this prevents third parties such as Cover Genius and its associated brands from sending emails to customers who opt into this service which presents a compliance issue for Cover Genius and you as a distribution partner.
Thankfully Apple provides a simple process for adding third-party domains. If you currently allow customers to "Sign in with Apple" or are planning to in the future please follow these steps to ensure customers receive emails from Cover Genius and its associated brands:
In , click More in the sidebar, then click Configure under Sign in with Apple for Email Communication.
In the Email Sources section, click the add button (+) on the top left.
Copy the following comma-delimited list: xcover.com,rentalcover.com,go.xcover.com,covergenius.com
Paste the comma-delimited list of Cover Genius domains that will be used for email communication, then click Next.
Confirm your entered email sources and click Register.
The table will display if the registered email source domain passed an SPF check.
All SPF checks should pass, if there is an issue please get in touch with your assigned CSE (Client Solutions Engineer) or Partner Growth Manager.
Customers will now be able to receive email communication from Cover Genius and its associated brands.
Frequently asked questions by developers, devops, business analysts
Travel / Accommodation
Property / Renters
Parcel / Shipping
Product / Retail
FAQs specific to insurance policies in the events space
XCover uses conventional HTTP response codes to indicate the success or failure of API requests. Error codes ranging from 200 to 299 indicate successful operations. Error codes ranging from 400 to 499 represent various error codes. Errors that can be resolved programmatically will result in an error code that briefly explains the error type and the reason for failure. 5xx codes indicate an unexpected error within the XCover application. In the unlikely event of a 5xx error, our engineering team will automatically receive a notification and will fix the issue as fast as possible.
Status
Description
200 - OK
Everything worked as expected
201 - Created
The request has been fulfilled and has resulted in one or more new resources being created
400 - Bad Request
The request was not accepted, often due to the wrong format of the request
401 - Unauthorized
No valid API key was provided
404 - Not Found
The requested resource doesn't exist
409 - Conflict
The request conflicts with another request, perhaps due to the usage of the same idempotency key
422 - Unprocessable Entity
Validation failed or logical error
429 - Too Many Requests
Too many requests hit the API too quickly. We recommend an exponential back-off of your requests.
500, 502, 503, 504 - Server Errors
Something went wrong on XCover side
Webhooks allow partners to be notified when important events happen in XCover. When one of those events are triggered, we will send an HTTP POST payload to the webhook's configured URL. Webhooks can be used to send a customer notification, initiate a policy renewal process or perform any custom logic. To establish webhooks, partners can provide to their CSE: 1. Listener URL 2. Authentication Key & Secret 3. Support URL 4. Requested events (CSE may propose or suggest these as part of solutioning).
We will provide an HTTP signature generated on our end in Authorization
header and the api key itself in X-Api-Key
header. We will base the signature on your provided key pair. You can use the same HMAC
based algorithm for signature verification, if required. Please use the information from the signature header to check which hash algorithm is used in order to validate the request. Currently, webhook requests are signed using sha256
algorithm.
In case of multiple failures with the webhook notification, where the partner supplied endpoint does not respond with a 200 OK, we will try the webhook for up to 3 times.
Description: The payload is sent in a webhook to the Partner whenever the Booking is Created through an API Request.
Description: The payload is sent to the Partner whenever the Booking is Updated through an API Request
Description: The payload is sent to the Partner whenever the Booking is cancelled through an API Request
Description: Used to notify partner about approaching renewal.
Example:
Description: Sent on the renewal due date, the customer policy will be active until the end of the grace period (expiry_date
).
Example:
Description: Sent on the renewal expiry date, the customer policy is considered canceled after this event is sent.
Example: