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.

Integration outline

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.

Quote

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.

Booking

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.

Modifications

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.

Cancellation

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.

Renewals

XCover.com also offers automatic renewals when it is required by the integration.

Claims

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.

• Choose the right workflow based on nature of business

  • Events / Tickets

• 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

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.

1. A simple script is used as a wrapper for the quote request

2. If custom display settings are required, they may be applied using signals or taken from quote request variables (see below example).

3. Using Content Delivery Network (CDN), offers are displayed within the purchase flow on partner site.

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

Important: Most display variations are handled by quote request attributes for example the currency display could be set as Indonesian Rp (IDR):

Custom Variable Display Requirements

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

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.

Sending Opt-Out Data

POST

Commonly, partners will integrate XCover using two key purchase process API calls: and . Most integrations follow the below high level flow of events:

1. User goes through a property related User Experience 2. Partner platform sends a to the create quote endpoint 3. User selects insurance option/s 4. User pays for travel and insurance at checkout 5. 6. Partner sends a to the create booking endpoint 7. XCover sends confirmation email including policy details, Partner sends purchase confirmation and tax invoice.

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 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: Modification: Certificate of Insurance (COI): Policy Disclosure Statement / Policy Wording (PDS): 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.

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)

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

Post sale processes

Should a partner need to facilitate policy cancellation (for example, a product return, or order cancellation), the below workflow should be referenced.

Opt-out process

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.

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

Post sale processes

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.

Claims Handling

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.

First Notice of Loss (FNOL)

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 .

Claim Assessment

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 and Emergency Claims

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.

Can we integrate claims submission ourselves?

Generally, claims are solely managed by Cover Genius. If you wish to discuss integrating claims submission into your experience, please contact your partnership manager.

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.

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.

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.

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: and . 💡 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 to the create quote endpoint 4. User selects insurance option/s 5. User pays for travel and insurance at checkout 6. 7. Partner sends a to the create booking endpoint 8. XCover sends confirmation email including policy details, Partner sends purchase confirmation and tax invoice.

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.

Single Payment

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 for more information.

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

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: and . 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. 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.

Common FAQs by Insurance Vertical

Travel / Accommodation

Property / Renters

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:

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.

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 Dual Payment method 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 Dual Payment method. 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:

API Errors

(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

The API adheres to the REST principles and provides developers-friendly, predictive and logically organised resource-oriented structure.

Dates

XCover API accepts date and date-time parameters in the format as defined by , for example 2018-01-01

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):

1. Price

2. Disclaimer

3. Policy wording link

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

3. Policy Wording, taken from the "pds_url" quote response field, for example: "view wording" as a hyperlink of: "ABCD-1234-INS"

Generally, the quote display should address:

1. Customer relevance - Does the quote/product presentation make sense for this purchase flow?

2. Compliance and regulatory requirements - Does the offer meet requirements for disclaimers, price, statements of fact, and availability of policy wording?

3. Marketing copy and trust - Is the offer likely to be understood and selected by the customer? Is the offer trusted/compelling?

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.

Generate HMAC Signature

XCover API uses HMAC-based authentication.

To authenticate API request the client application needs to perform the following steps:

1. Prepare request data for signing.

2. Sign data using one of the HMAC algorithms such as SHA1 (dprecated), SHA256 , SHA384 or SHA512 algorithms.

Below you can see an example code implementing these steps, this code can be used as a pre-request script in Postman.

Testing API Keys

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.

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.

Quote for Renewal

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.

Path Parameters

Headers

Confirm Renewal

To confirm a renewal once payment has been collected a request to the following endpoint needs to be made.

Confirm Renewal

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.

Path Parameters

Headers

Request Body

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 Fast Quote Request

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

Request a Quote

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

Path Parameters

Query Parameters

Headers

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.

Policy Instalment Options

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.

Confirming Instalment Plan

The instalment plan can be selected by provide the desired instalment name in the instalment_plan attribute during a booking request.

Processing a Periodic Payment

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.

Fetching Payment Plan Details

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.

Fetch Instalment Details

GET https://api.xcover.com/x/partners/:partner_id/bookings/:quote_package_id/instalments/

Returns instalment details including the payment schedule.

Path Parameters

Headers

Confirming an Instalment Transaction

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.

Confirm Instalment

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.

Path Parameters

Headers

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.

Make a Booking

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

Path Parameters

Headers

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.

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.

Sending Payment Details

The XPay API uses a long lived JSON Web Token (JWT) which will be provided to you by the assigned Client Solutions Engineer (CSE).

Tokenize Card Details

POST https://api.xpay.xcover.com/customer-tokens

This API call will tokenize the customers credit card details.

Headers

Making a Booking

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.

Make a Booking

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

Path Parameters

Headers

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.

Make an Instant Booking

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

Path Parameters

Headers

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.

Booking Retrieval

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.

Retrieve a Booking

GET https://api.xcover.com/x/partners/:partner_id/bookings/:quote_package_id

Retrieves a specific booking by providing the quote package ID.

Path Parameters

Headers

Booking Cancellation

Once a booking has been retrieved, check the can_be_cancelled flag is set to true in the response before issuing a cancellation request.

Cancel Booking

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.

Path Parameters

Headers

Preview a 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.

Preview Cancellation

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.

Path Parameters

Headers

Confirm Cancellation

To confirm a cancellation that has been previewed a request to the following endpoint needs to be made.

Confirm Cancellation

POST https://api.xcover.com/x/partners/:partner_id/bookings/:quote_package_id/confirm_cancellation

Confirm the previewed cancellation.

Path Parameters

Headers