Integrating the LIC premium engine inside BLISS Tab

BLISS Tab keeps a working copy of LIC's plan catalog on an agent's phone — mode-wise premium tables, approximate returns with bonuses, rider charges, and medical-requirement bands — and recomputes a quote the instant a client's age or sum assured changes. The numbers are only ever as good as the last sync from BLISS Infosoft's servers. That sync is where an integration lives. When a team wants those premium figures inside their own CRM, quoting page, or commission tracker, the work is reaching the catalog the app already pulls and keeping it current downstream.

The bottom line is short. The product data — premiums, bonuses, riders — is LIC's and non-personal, so it moves freely once modeled. The catalog-sync path carries most of the weight; a consenting agent login fills in their own saved presentations; native share output is the cheap fallback. We would build against the sync and put a freshness watcher in front of it.

What the calculator actually holds

Each row below is a surface the app exposes to the agent, mapped to where it comes from and what an integrator does with it.

Three authorized ways in

Each route states what is reachable, the effort, how durable it is, and what we set up to run it. Access is arranged with you during onboarding — a licensed agent account or a consenting device — so none of this is a hoop you clear before we start.

1 · Interface integration on the catalog sync

The app fetches its plan master and rate tables from BLISS Infosoft. Capturing that traffic under a licensed agent's authorization yields the premium tables, bonus rates, and rider charges in their raw shape. Reachable: the full priced catalog. Effort: medium — the schema has to be read off the wire and modeled. Durability: it tracks the app's own sync, so a release that reshapes the tables means a re-validation pass, which we plan for rather than patch later. We set up a consented test device and record the sync to map field names and units.

2 · Consented agent login

Where the app holds an agent's saved presentations and client list server-side, the agent's own login reaches them. Reachable: that agent's quotes, presentations, and saved clients. Effort: low to medium. Durability: stable while the login and token flow hold. We handle the token chain and keep the credentials inside the agent's own session.

3 · Native export capture

The share action emits a rendered quote or presentation over WhatsApp, SMS, email, or PDF. Reachable: finished output only, no structured fields. Effort: low. Durability: high but lossy. This is the fallback when a team needs the artifact, not the underlying numbers.

For most teams the sync route is the spine and the other two hang off it: the login route adds an agent's own work, export capture grabs whatever the app already renders. We would start on the sync and earn the structured premium data first.

What lands in your repo

Deliverables map to BLISS Tab's real surfaces, code first.

• Runnable client, Python and Node.js. Issues a premium query for one LIC plan — plan code, age, term, sum assured, mode, riders — and returns the structured quote with base premium, rebates, rider load, net premium, and the bonus projection.
• Catalog watcher with webhook push. A small service that re-pulls the plan catalog, diffs it against the last version, and fires a webhook to your endpoint when a premium table or bonus rate actually moves, so a downstream CRM learns about an LIC revision without polling for it.
• Automated test suite. Golden premium values pinned per plan, age, and term, so each quote can be checked against known-good figures whenever the catalog changes.
• Normalized schema. A common shape for plan, premium, rider, and bonus rows across the LIC catalog, so two plans read the same way.
• OpenAPI / Swagger description of the modeled surface, for whoever consumes the client.
• Protocol and auth-flow report covering the agent token chain and the catalog-sync calls.
• Interface documentation plus DPDP-aligned data-retention notes for any client data the build touches.

A premium query, sketched

This is the core surface — a single plan's premium, the way the app computes one. Field names are reconstructed from the app's own traffic during the build, not published by the vendor, so read the snippet as illustrative shape rather than a fixed contract.

# Modeled premium query for one LIC plan (BLISS Tab calc surface)
# Names/values illustrative; confirmed against the app's traffic at build time.

POST /tab/premium/quote
Authorization: Bearer <agent-session-token>   # from the licensed agent login
Content-Type: application/json

{
  "plan_no": 914,           # LIC plan code (example: an endowment plan)
  "age": 32,                # or "dob"
  "term": 21,
  "ppt": 21,                # premium-paying term
  "sum_assured": 500000,
  "mode": "HLY",            # YLY | HLY | QLY | MLY
  "riders": ["AB", "TR"]    # accidental benefit, term rider
}

200 OK
{
  "tabular_premium": 27340.0,
  "mode_rebate": -120.0,
  "sa_rebate": -50.0,
  "rider_premium": { "AB": 250.0, "TR": 1180.0 },
  "net_premium": 28600.0,        # base after rebates + riders
  "dab_cover": 500000,
  "bonus_projection": [ {"year": 5, "vested_bonus": 11500.0}, ... ]
}

# Notes: rebate order matters. Mode and high-SA rebates apply to the
# tabular premium before rider load is added — reproduce that order or
# the net premium drifts from what the agent sees on screen.

Where teams plug this in

• An agency CRM that wants a live premium next to each lead, instead of re-keying figures an agent already calculated in BLISS Tab.
• A web quoting page that calls the modeled endpoint so a prospect sees the same net premium the agent would read off the app.
• A commission and renewal tracker that pulls plan and rider data to project payouts per policy.
• A back-office that ingests shared PDFs and reconciles them against the structured quote behind them.

Client data, the DPDP Act, and IRDAI

The split is clean and worth stating plainly. LIC plan tables, bonus rates, and rider charges are product data — non-personal, and the bulk of what an integration moves. The personal data is whatever an agent types about a prospect: name, age, sum assured, contact. That falls under India's Digital Personal Data Protection Act, 2023, with the agent acting as data fiduciary, so we process it with consent, minimize what is stored, and keep consent and access records. IRDAI, which regulates agent conduct, set up a task force in late 2024 to work through how the DPDP Act lands on insurers and intermediaries, so the operating posture here is to hold client data lightly and keep the product data the focus. We work from authorized, documented, or user-consented access, log what we touch, and sign an NDA where the engagement calls for one.

Build notes specific to BLISS Tab

Two things shape this build more than anything else.

Catalog drift. LIC revises premium and bonus tables and adds plans, and the app picks those up on its own cadence — agents have publicly grumbled about stale plan details. We version each catalog pull and pin golden premium values, so a revised rate surfaces as a failing test rather than a wrong quote reaching a client.

On-device versus server math. Part of the premium computation runs locally from synced rate tables and part leans on a server call. We work out during the build which fields come from the sync and which are computed on the handset, then reproduce the local formula so our output matches the app to the rupee.

Rebate and rider order. Mode rebate, high-sum-assured rebate, and rider premium stack in a specific sequence; we model that order explicitly because getting it wrong shifts the net premium an agent would quote. Access to a licensed account or a consenting device is arranged with you as part of onboarding, not asked for up front.

Cost and how delivery runs

A first drop is usually a single plan's premium query, wrapped as a Python or Node client with tests, in your hands within one to two weeks. From there you pick how to take it. Source-code delivery starts at $300 — you get the runnable source and docs, and you pay after delivery once the quotes are matching and you are satisfied. Or run it as a pay-per-call hosted API: you call our endpoints, pay only for the calls you make, with no upfront fee. Tell us the app and what you want out of its data, and we scope the rest. Start a conversation about BLISS Tab.

The screens this is read from

Store screenshots of the calculation and presentation surfaces — open one to view it full size.

Sources and how I checked

Checked on 14 June 2026 against the developer's own product pages and the Play listing, with India's data-protection position read off legal and advisory write-ups. Specifics on premium modes, bonuses, riders, and medical requirements come from BLISS Infosoft's BLISS Tab product page and the Google Play listing (package com.bliss.bliss_tab, per that listing). The DPDP and IRDAI position draws on PwC India on the DPDP Act and insurance and reporting on the IRDAI task force on the Act.

Compiled by OpenFinance Lab — ingestion engineering, 14 June 2026.

Other tools in the same agent stack

Neighbouring apps an LIC-agent integration tends to meet. Listed for context, not ranked.

• LIC Agent App — free agent tool bundling plan information with a built-in premium calculator.
• LIC Ananda — LIC's own digital app for agents to onboard new business, with proposal capture and e-KYC.
• LIC Customer App — LIC's official policyholder app showing policy status, premiums due, and bonus.
• BLISS Tab Plus — sibling presentation tool with year-wise risk cover, net premium, and tax-saved views.
• BLISS Agent Advisor — sibling agency tool for keeping agent and client records in one place.
• InsureMax — BLISS Infosoft's CRM module tracking clients, policies, and renewals.
• Policybazaar — aggregator portal hosting LIC and multi-insurer premium calculators.
• Turtlemint — POSP advisor platform with multi-insurer quotes and commission tracking.
• InsuranceDekho — POSP agent platform for quoting and policy issuance across insurers.

Questions integrators ask

How current are the LIC plan tables you pull, given the app itself sometimes lags a revision?

We version every pull and diff it against the last, so a revised rate or a brand-new plan shows up as a change you can see, and we can push that change to your endpoint by webhook. We cannot be fresher than what BLISS Infosoft pushes down to the app, but we can tell you the moment a revision lands instead of leaving you to notice a wrong quote later.

Does the premium math run on the device or on a server?

Both, depending on the field. Some plans recompute locally from synced rate tables; others lean on a server response. During the build we separate the two and reproduce any on-device formula so our quotes match the app to the rupee, mode rebate and rider stacking included.

Whose data are we actually touching here, the agent's or the policyholder's?

The plan catalog, premium tables, and bonus rates are LIC product data, not personal information. Anything client-specific an agent has typed in, a name, an age, a sum assured, is personal data under India's DPDP Act 2023, so we keep it minimized, consented, and logged, with the agent treated as the data fiduciary.

Can you hand us just the premium-quote endpoint without the rest of the app's surface?

Yes. A single plan's premium query, wrapped as a Python or Node client with tests, is a common first drop. Bonus projections, rider charges, and presentation export can follow in a later pass once the core quote is matching.