DEV Community

Ujjawal Tyagi
Ujjawal Tyagi

Posted on

Architecture of ClaimsMitra: 114+ REST APIs for Insurance Survey Platform

Insurance in India runs on surveys. When a claim comes in—a car accident, a flooded basement, a health emergency—a surveyor physically visits the site, inspects the damage, documents it with photos and reports, and submits the assessment back to the insurer. The turnaround used to be 5–10 days. One of our clients at Xenotix Labs (https://www.xenotixlabs.com) wanted to get it to under 24 hours.

The result was ClaimsMitra—a mobile + web platform connecting insurers, surveyors, hospitals, garages, and claimants on one pipeline. We shipped 114+ REST APIs across 8 microservices, MySQL for core state, and a Flutter app that works offline for field surveyors in patchy network areas.

The domain complexity

Insurance is not one workflow. It's dozens. Motor claims flow differently from health claims from property claims from marine. Each has its own document requirements, approval hierarchies, fraud checks, and settlement paths. The first architectural decision was to avoid the "one giant workflow engine" trap. Instead we built per-domain state machines that share a common audit-log infrastructure but have independent business logic.

The 114 REST APIs

People ask why so many APIs. Insurance platforms have massive surface area: user types (surveyor, insurer, claimant, garage, hospital admin, agent), entity types (claim, policy, vehicle, document, estimate, settlement), lifecycle events (report, assign, inspect, estimate, approve, settle, reopen), and integrations (Razorpay for payouts, Aadhar OTP for KYC, multiple insurer APIs). 114 endpoints across 8 services turns out to be lean for the domain.

We grouped the services by bounded context: claims-core, surveyor-ops, document-vault, estimation-engine, settlement, notifications, analytics, admin. Each service owns its database tables and exposes APIs with contract versioning via URL prefix (/v1/, /v2/). Services talk to each other via HTTP for synchronous needs and RabbitMQ for async events.

Offline-first Flutter for surveyors

Surveyors work in places without network. We built the mobile app to capture photos, geotag, audio notes, and inspection reports fully offline, then sync when back online. Photos are stored locally, compressed to 200KB each, and queued for S3 upload. Inspection reports are structured JSON with a local SQLite store (Drift ORM). Sync reconciliation uses vector clocks to handle conflicts when the surveyor edits on two devices.

Document handling

114 APIs implies a lot of documents. We use S3 with presigned URLs for upload (no bytes go through our backend), virus-scan via ClamAV in a Lambda trigger, and persist metadata (hash, uploader, claim_id, visibility) in MySQL. PDFs get OCR'd via Textract for searchability.

Results

Median claim settlement time went from 7 days to 18 hours. Surveyor productivity 2.3x (fewer callbacks because of better first-visit capture). Fraud-reject rate up by 12% (better data means better detection).

About Xenotix Labs

We're a product engineering studio in India. 30+ products shipped including Veda Milk (D2C dairy), Cricket Winner (real-time cricket on Kafka + WebSockets), Legal Owl (LegalTech super-app), Growara (AI WhatsApp automation), and 7S Samiti (offline AI tutor for rural India). Flutter, Next.js, Node.js on AWS. Visit https://www.xenotixlabs.com or email leadgeneration@xenotix.co.in.

Top comments (0)