KASKO JS
Before you start this guide you will need Keys.
Integration KASKO JS
Include the following JS snippet in the HEAD of the page or at above where you want the widget to be created.
Snippet can be acquired in Product Builder product's Integration section.
Widget Container
Add a container div where you want the widget to be created on the page.
This can be given any ID but we have used kasko-widget-container
in our example below. This container can be set with any width, but should be left “height:auto” so that KASKO JS can handle the height responsively.
Webview Mode
This is the default, if no mode is configured. It loads widget inline on the page and adjusts height of the container automatically based on then height of widget contents.
Popup Mode
If you wish to have the widget popup in a new window instead of loading inline on the page please add the following to the Kasko.Setup method detailed below.
When using popup mode the container attribute is the target which KASKO JS will attach the click event handler too.
Full Screen Mode
If you wish to have the widget to consume the whole page instead of loading inline on the page please add the following to the Kasko.Setup method detailed below.
Setup KASKO JS
Below the widget container div include the widget setup javascript
Parameters
Widget setup parameters
Parameter | required | Type | Description |
---|---|---|---|
container | yes | string | ID of the div you want the KASKO Widget to appear in. |
key | yes | string | TEST or LIVE client key provided by KASKO. |
language | yes | string | Language in which the product should be shown in. |
app | yes | string | App types. Allowed values are |
integration | no | string | Integration ID provided by KASKO. Required for |
touchpoint | no | string | Touchpoint ID provided by KASKO. Required for everything except the portal app. |
data | no | data object | Prefill data. |
metadata | no | data object | Additional, non-validated data stored on all policies. |
config | no | config object | Specific product configuration. |
callback | no | object | Custom callbacks triggered at various stages within the application. |
Generic Optional data parameters
These fields can be provided to the data object.
These fields can pre-populate widget data or be used to pass extra information
Parameter | Type | Description |
---|---|---|
first_name | string | First name of the customer - This will pre-populate in the widget |
last_name | string | Last name of the customer - This will pre-populate in the widget |
string | Email Address of the customer - This will pre-populate in the widget |
Please see product specific page for product specific optional data parameters.
Generic Optional config parameters
These fields configure the application depending on the needs of the page.
Parameter | Type | Description |
---|---|---|
header_visibility | string[] | On what devices should the header be visible? Defaults to ALL devices. |
footer_visibility | string[] | On what devices should the footer be visible? Defaults to desktop and tablet. |
hamburger_visibility | string[] | On what devices should the hamburger side menu be visible? Defaults to mobile. |
Available device types: desktop, tablet, mobile. If no device type is defined ([] - empty array), then this section will not be visible on any device.
Please see product specific page for product specific optional config parameters.
Callbacks
Sometimes it's necessary to add custom functionality on some event. For example, tracking every policy purchase to an external tool. This can be achieved via callbacks.
Example callback
Available callbacks
Parameter | Description |
---|---|
policy_purchase | Triggered when a policy has been successfully created and paid for. |
Go Live
When testing is complete and you're ready to Go Live, please swap the Client TEST key for the Client LIVE key in your production site.
You must swap you client key with the LIVE client key before going live.
Querystring Prefill
Sometimes it's useful to prefill a webapp with predefined data. For example, an email campaign may have a link to the webapp integration. In order to store the email campaign tracker ID on the customer's policy, query string prefill can be used.
?kdata=eyJmaXJzdF9uYW1lIjoiSm9obiJ9
kdata is short for KASKO data. This querystring parameter is used to prefill an application with given data (name, address, email, etc) and metadata (could be anything, but most commonly used for analytics tracking data or agent information).
kdata can only be used on the integration level. It will not work if set on webapp level (webapps.kasko.io domain). This is because KASKO JS is responsible for decoding kdata and passing it on to the webapp in a different format.
kdata value can be a url-safe-base64-encoded string or a JSON string. It is preferred to use url-safe-base64-encoded string as it is supported by all browsers.
Example url-safe-base64-encoding (uses js-base64 dependency):
Examples
url-safe-base64-encoded string (only data):
url-safe-base64-encoded string (data + metadata):
JSON string (only data):
JSON string (data + metadata):
What's url-safe-base-encoded string? This is a base64 encoded string that has all the trailing equals signs removed from it.
Limitations
Some older browsers have strict max URL length limits after which the URL gets truncated. If this limit is breached, the base64 or JSON value gets broken. In general it is recommended to have the URL length below 2000 characters long. Read this StackOverflow explanation for more information.
Last updated