Bimafy: Get Insurance & Claims — API integration & OpenInsurance services

Deliverables checklist

• API specification (OpenAPI / Swagger) for login, policies, quotes and claims
• Protocol & auth flow report — OTP/phone login, bearer-token lifecycle, cookie/header chain
• Runnable source for policy export and claim-status APIs (Python / Node.js)
• Automated test suite, Postman collection and API reference documentation
• Compliance guidance — e-KYC handling, consent capture, retention and Insurance Act 2010 / IDRA alignment

Feature module — Account login API

Mirror the app's phone-number + OTP authorization, persist and refresh the session token, and expose a stable account_id. Concrete use: a broker back-office links a customer once and then pulls that customer's policy and claim data on a schedule without re-prompting for OTP each run.

Feature module — Policy & coverage API

Return every active and lapsed policy with carrier, product type, sum insured, start/end date, remaining duration and premium-due list. Concrete use: a corporate HR dashboard reconciles group-insurance certificates for employees against payroll deductions each month.

Feature module — Quote comparison API

Submit a cover request (e.g. private car, 1500cc, Dhaka) and receive the same ranked multi-insurer quotation set the app shows, with premium, add-ons and validity. Concrete use: an embedded-insurance widget on an e-commerce checkout calls this to display three live options instead of one hard-coded quote.

Feature module — Claim portal & status API

Create a claim, attach the required document checklist, and poll or subscribe to status transitions with timestamps and assisted-journey notes. Concrete use: a workshop management system shows the live motor-claim stage to a customer and triggers an SMS when "approved/settled" fires.

Feature module — Offers & renewal feed

Pull the partner-company discount feed and the per-user renewal queue (policies expiring in the next N days). Concrete use: a marketing automation tool builds a renewal campaign segment and appends a relevant partner discount to each message.

1. Embedded motor insurance at point of sale

Context: a vehicle dealer or helmet retailer wants to offer cover at checkout — mirroring the real LS2-Helmets-with-accident-cover style of partnership Bimafy has run with distributors. Data/API: the quote comparison endpoint (vehicle attributes in, ranked carrier quotes out) plus a purchase-handoff and a policy-document fetch. OpenInsurance mapping: the quote-and-bind flow is exposed as a consent-scoped product API, so the dealer's system never stores raw credentials — it holds only a token and the issued policy reference.

2. Corporate group-insurance reconciliation

Context: an HR/ERP team manages employee group health and life cover and must reconcile certificates, additions and removals each month. Data/API: account login (corporate account) → policy & coverage API filtered to group products → premium schedule → policy-document export. OpenInsurance mapping: a server-to-server read scope returns normalised policy and member objects that drop straight into the HRIS, replacing emailed spreadsheets.

3. Claim-status notifications for a workshop or hospital desk

Context: a motor workshop or hospital cashier wants to show the customer where their claim stands and act when it settles. Data/API: claim status API + webhook subscription on stage transitions (submitted, under_review, docs_requested, approved, settled). OpenInsurance mapping: event payloads carry only the claim id, stage and timestamp; the desk app resolves details with a follow-up authorized call — minimal data on the wire.

4. Renewal & cross-sell automation

Context: a marketing platform wants a "policies expiring in 30 days" segment plus a matching partner discount. Data/API: renewal queue endpoint + partner offers feed, joined on product category. OpenInsurance mapping: the renewal list is a derived, consent-bound view — no premiums or NID values leave Bimafy unless the customer's scope explicitly allows it.

5. Personal finance & insurance aggregation

Context: a money-management app in Bangladesh wants users' insurance alongside bank and bKash data for a full net-worth and protection view. Data/API: account login → policy list → premium schedule → claim history, all read-only. OpenInsurance mapping: this is the classic account-aggregation pattern from open finance, applied to the insurance leg — the user grants a scoped, revocable consent and the aggregator pulls a standard JSON contract.

1) Phone + OTP login and token refresh

// Step 1 — request OTP
POST /api/v1/bimafy/auth/otp/request
Content-Type: application/json
{ "phone": "+8801XXXXXXXXX" }

// Step 2 — verify and receive tokens
POST /api/v1/bimafy/auth/otp/verify
{ "phone": "+8801XXXXXXXXX", "otp": "123456" }
200 OK
{
  "account_id": "acc_8f21c0",
  "access_token": "eyJ...",        // short-lived
  "refresh_token": "rt_9be1...",   // store securely
  "expires_in": 1800
}

// Step 3 — refresh
POST /api/v1/bimafy/auth/token/refresh
{ "refresh_token": "rt_9be1..." }
401  -> { "error": "refresh_expired", "action": "re_authenticate" }

2) Export policies & premium schedule

# Python
import requests
H = {"Authorization": f"Bearer {ACCESS_TOKEN}"}
r = requests.get(
  "https://api.example.com/v1/bimafy/policies",
  headers=H,
  params={"status": "active", "include": "premiums,documents"},
)
r.raise_for_status()
for p in r.json()["policies"]:
    print(p["policy_no"], p["carrier"], p["product_type"],
          p["sum_insured"], p["valid_to"], p["days_remaining"])
    for due in p["premiums"]:
        print("  ", due["due_date"], due["amount"], due["status"])

# 200 -> { "policies": [ { "policy_no": "...", "carrier": "...",
#   "product_type": "health|motor|travel|life|commercial",
#   "sum_insured": 500000, "valid_from": "2025-09-01",
#   "valid_to": "2026-08-31", "days_remaining": 111,
#   "premiums": [ { "due_date": "2026-03-01", "amount": 4200,
#                   "status": "paid|due|overdue" } ],
#   "documents": [ { "type": "certificate", "url": "..." } ] } ] }
# 429 -> back off using Retry-After header

3) Claim creation + status webhook

// Create a claim
POST /api/v1/bimafy/claims
Authorization: Bearer <ACCESS_TOKEN>
{
  "policy_no": "MTR-2026-00891",
  "type": "motor_own_damage",
  "incident_date": "2026-05-03",
  "amount_claimed": 38000,
  "description": "front bumper, headlamp"
}
201 -> { "claim_id": "clm_4a7d", "stage": "submitted",
         "documents_required": ["fir","estimate","photos"] }

// Webhook delivered to your endpoint on each transition
POST https://your-app.example/webhooks/bimafy
X-Bimafy-Signature: sha256=...
{
  "event": "claim.status_changed",
  "claim_id": "clm_4a7d",
  "stage": "approved",          // submitted|under_review|docs_requested|approved|settled|rejected
  "at": "2026-05-09T11:42:00+06:00"
}
// Verify X-Bimafy-Signature (HMAC) before trusting the payload;
// respond 2xx within 5s or it will be retried with backoff.

Regulatory alignment

Insurance in Bangladesh is regulated by the Insurance Development and Regulatory Authority (IDRA) under the Insurance Act 2010 and the IDRA Act 2010. IDRA has rolled out a Unified Messaging Platform (UMP) with a policy repository, e-Receipt, e-KYC, e-Agent approval and a "Bima Tathya" policyholder app, and is moving toward centrally stored e-policies that carry the policyholder profile, policy terms, premium payment history and policy status. Any Bimafy integration we build is positioned to fit that direction — read-only where possible, consent-scoped, and auditable.

How we keep it lawful

• Access only under client authorization or documented public/authorized endpoints — no credential sharing in the clear.
• Explicit, revocable consent records per end user; data-minimisation on every payload (ids and stages over raw NID/premium values).
• Access logging, signed webhooks (HMAC), TLS in transit and encryption at rest; retention windows agreed in writing.
• Alignment with Bangladesh's emerging personal-data-protection rules and, for cross-border clients, GDPR-style controller/processor terms; NDAs on request.
• No reverse engineering of payment-card data or anything outside the agreed scope; clear escalation path if an endpoint changes.

• One by MetLife (formerly MetLife 360Health), Bangladesh — holds policy details, tele-doctor consultations, claims and wellness data for a large policyholder base; partners often need its claim status alongside Bimafy's.
• Guardian Life Insurance app, Bangladesh — life and health policy servicing, premium schedules and claim tracking; a common second source in a Bangladesh insurance dashboard.
• Pragati Life Insurance, Bangladesh — life policy records, premium payment history and surrender/maturity data that pair naturally with marketplace exports.
• Bima Tathya (IDRA Unified Messaging Platform app), Bangladesh — the regulator's policyholder app and policy repository; the reference point for e-policy and e-KYC data formats.
• PolicyBazaar, India — multi-insurer quotes, purchased policies and claim assistance; the canonical example of marketplace quote data many integrators already know.
• Turtlemint, India — auto, bike, health and term-life policies plus an advisor network; relevant when a partner spans both markets.
• Digit Insurance, India — motor, travel, health and gadget cover with API-led issuance and claims; often cited for self-service claim data.
• Acko, India — digital-native motor, health and embedded insurance; policy and claim objects similar in shape to a marketplace's.
• Bimaplan, India — affordable health and life micro-insurance distributed through partners; comparable micro-policy and premium-collection data.
• Sunday (Jolly super app), Thailand — full-stack insurtech with health policy management and hospital network data; a regional analogue for app-protocol integration work.

About us

We are an independent technical studio focused on app interface integration and authorized API integration for fintech and insurtech. Our engineers come from banks, payment gateways, insurers and protocol-analysis backgrounds; we ship end-to-end APIs under security and compliance constraints rather than throwing scripts over the wall.

• Insurance, payments, digital banking and cross-border data integration
• Protocol analysis, OAuth/token flows, mobile app interface reverse engineering (lawful, authorized)
• Custom Python / Node.js / Go SDKs, webhook infrastructure and test harnesses
• Full pipeline: protocol analysis → build → validation → compliance review → handover
• Source-code delivery from $300 — runnable API source plus full documentation; pay after delivery upon satisfaction
• Pay-per-call API billing — hosted endpoints, usage-based pricing, no upfront cost; ideal for teams that prefer to scale spend with volume

Contact

To request a quote or hand over your target app and requirements (data needed, regions, expected volume), open our contact page:

Contact page

Tell us which Bimafy data you want — policies, multi-carrier quotes, claim status, premium schedules or partner offers — and your preferred model (source-code delivery or pay-per-call).

Engagement workflow

1. Scope confirmation — which Bimafy data and which scenarios (login, policy export, quote comparison, claim status, offers).
2. Protocol analysis & API design — 2–5 business days depending on complexity.
3. Build & internal validation against a test account — 3–8 business days.
4. Documentation, Postman collection and test cases — 1–2 business days.
5. Handover and support window; third-party approvals or app changes may extend timelines. Typical first delivery: 5–15 business days.

FAQ

What do you need from me to start a Bimafy integration?

How long does delivery take?

How do you handle compliance and privacy?

Can you deliver runnable source code instead of a hosted API?