> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.kota.io/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.kota.io/_mcp/server.

# Key Concepts

> Understand the key concepts that power all Kota integrations

Whether you're using Kota's Hosted Page, Embed SDK, or building directly with our APIs, these concepts form the foundation of every integration.

## Platform

A **platform** represents a customer platform that integrates with Kota to offer benefits to employers and employees. Platforms use Kota's developer products to provide insurance and benefits services to their customers.

---

## Employer

An employer represents a legal entity in a specific country that provides policies to its employees.

Employers transition from `pending` (during regulatory checks) to `active` (ready to set up a group policy). Create employers early in your integration to ensure they're ready when needed.

[View Employer API documentation](/api-reference/employers/list-employers)

---

## Employee

An employee represents an individual who receives policies from their employer. Employees can add dependants - such as spouses, partners, or children.

Like employers, employees start in `pending` status during processing, then move to `active` once ready.

[View Employee API documentation](/api-reference/employees/list-employees)

---

## Group

A group provides a unified abstraction for managing policies. Instead of handling each policy type separately - such as health insurance, life assurance, or pension a group offers a single, consistent interface for all.

**Why groups matter**

Groups simplify integration. Whether you’re offering one type of policy or many, the interaction model remains the same. This allows you to:

* Use one interface for all policy types
* Offer multiple instances of the same policy per employer (e.g., different health plans for different employee segments)
* Manage multiple policies together as a bundle (e.g., in Canada, Life Assurance is required alongside Health Insurance; in such cases, the provider bundles them together)

**Multiple instances example**

* **Single setup:** An employer offers one plan company-wide. You create a group called "Health Plan" that manages this group policy.
* **Multi-instance setup:** An employer offers two plans across the company. You create groups called "Executive Health Plan" and "Core Health Plan" to manage the policies for different employee segments.

**Bundles**

> **Warning**
>
> Bundles cannot be split. If a group contains multiple benefits, they must all be managed as a unit.

When multiple policy types are designed to work together - such as health insurance and life assurance they form a **bundle**. In these cases, you must act on the entire bundle as a single unit, simplifying setup, management, and enrollment.

Bundles are predefined combinations of compatible policy types, configured according to country-specific regulations and provider requirements. Customization of bundles is currently unavailable.

**Examples**

* **Single policy:** An employer offers one health insurance plan. You create a group called "Health Plan" that manages this group policy.
* **Bundle:** An employer offers health insurance and life assurance as a bundle due to country requirements. You create a group called "Core Benefits" that manages both policy types as a bundle, allowing employees to enroll in both simultaneously through a single flow.

[View Groups API documentation](/api-reference/groups/)

---

## Group Policy

A **group policy** represents the collective benefit configuration established by an employer at the group level. When an employer sets up a plan for a group, Kota creates a corresponding group policy with a designated provider. This applies to all benefit types, including but not limited to health insurance, pension, and life assurance.

**What a group policy defines**

* Policy provider and product
* Plan terms and conditions
* Policy lifetime and renewal dates
* Enrolled employees

Think of it as the master contract between the employer and benefit provider: all enrolled employees receive their policies under this collective arrangement.

[View Group Policies API documentation](/api-reference/group-policies)

---

## Policy

A **policy** is the individual benefit issued to each employee who enrolls in a benefit. When an employee accepts coverage, they receive their own policy derived from the overarching group policy. Policies apply across multiple benefit types, including health insurance, pension, life assurance, and more.

**What a policy includes**

* Policy information for the employee and any dependants
* Terms inherited from the group policy
* Individual lifecycle (start date, changes, termination)

**Example**

ABC Co Limited creates a health insurance group backed by Allianz. Kota establishes an Allianz group policy. When Jane enrolls, she receives her own health insurance policy under that group policy, including her personal details and any dependants. The same structure applies if ABC Co creates a pension group or life assurance group: each benefit type follows this group policy → individual policy model.

[View Policy API documentation](/api-reference/policies)

---

## Intent

An **intent** tracks an action that takes time to complete, such as getting a quote, setting up a group policy, or enrolling an employee. Instead of getting a result straight away, you create an intent and follow its status until it finishes.

Intents exist because most benefit actions depend on things outside your platform: a provider has to price a quote, an employee has to supply details about their dependants, or internal customer verification checks have to run.

**How an intent works**

1. **Create** - Your platform creates the intent, or Kota creates it for you in some cases, such as a group policy intent.
2. **Provide information** - If Kota needs more information to process an application, the intent moves to `action_required` and lists the [requirements](/api/adaptive-requirements) to answer. Some intents have other steps for gathering information too, so check each intent's statuses for the full list.
3. **Confirm** - Some intents pause at `pending_confirmation` so the employer or employee can review the price or terms before you confirm.
4. **Complete** - The intent reaches a final status and creates its result, such as a group policy or an individual policy.

Every status change sends a [webhook event](/core-components/webhooks-and-events), such as `enrolment_intent.action_required`, so you can react without polling.

**Types of intent**

| Intent                       | What it does                                                                                    | Result                                               |
| ---------------------------- | ----------------------------------------------------------------------------------------------- | ---------------------------------------------------- |
| Group quote intent           | Requests a quote for a given provider and group                                                 | A quote the employer accepts or rejects              |
| Group policy intent          | Accepts a quote and gets it approved by the provider                                            | A group policy                                       |
| Enrolment intent             | Enrols an employee into the group policies for a given group                                    | A policy for the employee                            |
| Policy amendment intent      | Changes an existing policy, mainly to add dependants, record a qualifying life event, or cancel | An amended policy                                    |
| Dependents management intent | Manages dependants for a policy or enrolment, using the same logic across different flows       | Dependants applied to a policy, enrolment or renewal |
| Policy import intent         | Brings a policy the employee already holds with a provider into Kota                            | An imported policy                                   |

**Example**

ABC Co Limited wants health insurance for its UK staff. You create a group quote intent, and once the quote is available the employer accepts it. A group policy intent then sets up the group policy with the provider. When Jane joins the group, an enrolment intent asks for her dependants' details, waits for her to confirm the price, and then creates her policy.

[Learn more about the intent pattern](/api)

---

## How It Works Together

Here's how these concepts relate:

```
Platform (your application)
  └── Employers (legal entities in one country)
  ├── Employees (individuals receiving benefits)
  │     └── can be added to Groups
  └── Groups (unified benefit interface)
      └── Group Policies (collective insurance contracts)
          └── Policies (individual coverage for enrolled employees)
```

**The relationship flow:**

1. Platforms create employers to offer benefits
2. Employers create groups to offer benefits
3. Employees are added to Groups
4. Each group has a group policy with the insurance provider (set up through a group quote intent and a group policy intent)
5. When an employee enrols, they receive an individual policy under that group policy (handled through an enrolment intent)

Implementation details vary by integration type. See your specific integration guide for step-by-step instructions.

## Next Steps

Now that you understand the core concepts, learn about the different ways you can integrate Kota into your platform:

#### [Integration Types](/integration-types)

Compare Hosted, Embed, and API integration approaches to find the best fit for your platform