Automating motor insurance proposal forms with one API.

Ask anyone who works at an Indian insurance company what their team actually spends time on, and you will hear a version of the same answer. They are filling forms. Motor insurance proposal forms, mostly. The same form, the same fifteen or twenty fields, filled in by hand for a customer who emailed a photo of their RC book.

This post is about turning that work into one API call. Not a marketing pitch for our product, just a walkthrough of what the actual workflow looks like and what changes when the PDF stops being something a person fills out.

The proposal form, briefly

A motor insurance proposal form is the document a customer signs to apply for a policy. In India, the format is set by the insurer and reviewed by IRDAI. There are several family members in this family of forms:

• Private Car Package Proposal - the most common one, for individual owners.
• Two Wheeler Proposal - similar layout, smaller, plus an IDV declaration.
• Bharat Misc Commercial Lines Proposal - the standardised commercial vehicle form.
• Goods Carrying Vehicle Proposal - for trucks, tempos, and pickup vans.

Each form has its own preprinted layout, but the data going into it is roughly the same. Owner name and address, vehicle registration number, chassis number, engine number, manufacturer and model, year of manufacture, fuel type, cubic capacity, seating capacity, intended use, previous insurer (if any), no-claim-bonus declaration, sum insured (IDV), proposed cover, and a signature.

Most of this data the company already has. The customer typed it into the website. The RC book was already uploaded. The previous policy is in the CRM. The form is just a publisher.

The workflow today

Walk into a mid-sized broker office in Pune or Coimbatore and you will see this loop:

• Customer fills a Google Form or sends WhatsApp photos of their documents.
• An ops associate copies the data into a spreadsheet.
• The associate downloads the insurer-provided proposal form PDF, opens it in Adobe Reader, and types the data in.
• The form is printed, signed, scanned, and emailed back to the insurer.
• The insurer keys it in to their issuance system.

Five copies of the same data, three formats, two scans. A single broker doing fifty cases a day is keeping two people busy on what is essentially a transcription task.

Every time a person retypes a customer name into a PDF, something has gone wrong upstream.

The workflow with an API

Here is what the same loop looks like when the proposal form is a versioned template behind a REST API.

The broker uploads the insurer-provided form PDF once. They drop fields onto it - owner name, address, registration number, chassis number, sum insured, signature. Each field gets a snake-case alias. They publish v1 to production. That is the setup.

For each new customer, their backend now sends one HTTP request:

curl https://api.mezdoc.com/v1/templates/private_car_proposal_v1/submissions \
  -H "Authorization: Bearer $MEZDOC_KEY" \
  -H "Idempotency-Key: case_2026_05_19_00481" \
  -d '{
    "environment": "production",
    "data": {
      "owner_name":        "Priya Mehta",
      "address":           "12 MG Road, Bengaluru 560001",
      "registration_no":   "KA-01-AB-3344",
      "chassis_no":        "MA3ERLF1S00123456",
      "engine_no":         "K12MN-1234567",
      "make_model":        "Maruti Suzuki Baleno Zeta",
      "manufacture_year":  2023,
      "cc":                1197,
      "seating_capacity":  5,
      "intended_use":      "private",
      "previous_insurer":  "ICICI Lombard",
      "ncb_claimed":       25,
      "sum_insured":       742000
    }
  }'

The response is a submission id. Thirty seconds later a signed webhook fires with a link to the filled PDF. The associate opens it once to send the signature link to the customer and that is the day.

Where the savings actually come from

It is not the typing time. Typing fast was never the bottleneck. The savings come from four places.

One source of truth

The customer name lives in your CRM. Your CRM POSTs to the API. The PDF reflects the CRM. If the name is wrong, you fix it in one place. Before, the name lived in seven places and the canonical copy was whichever associate touched the record last.

Versioning that survives an audit

When IRDAI updates the proposal form, you publish v2 of the template. Every submission since the change carries `template_version: 2`. The audit trail tells you which forms went out on which template version, signed by whom. The previous workflow gave you a PDF in someone's email and a copy in a shared drive.

Conditional fields without three templates

Two-wheelers do not have a seating capacity row. Commercial vehicles do not have a private-use box. You handle this in the workflow with one condition per field. Anvil makes you duplicate the entire template. We keep one template and skip the row when it does not apply.

The signer is no longer a human at the desk

Once the API returns the filled PDF, you can send a tokenised link to the customer. They sign it on their phone with Aadhaar OTP, the audit record carries the IP, user agent, and SHA-256 of the rendered PDF. The proposal is now legally signed without anyone walking a print to the post office.

What you do not solve with the API

Three things stay your problem.

• The insurer still has to accept the proposal at their end. The API does not bypass underwriting.
• The customer still has to give you accurate data. You can validate format (PAN, GSTIN, vehicle registration regex) but not truth.
• If the insurer is on an offline system, you are still emailing a PDF. The API just makes producing the PDF cheap.

For the cases where the insurer is integrated, the API hands off the data directly and the PDF becomes a receipt. For everyone else, the PDF is the artefact that moves the file forward. Either way the human in the middle stops being a transcription station.

The US parallel

US readers will recognise the same pattern in their own market. The commercial auto proposal in the US is ACORD 137 (Commercial Auto Section). It carries the same kind of fields: insured legal name, garaging address, vehicle list with VIN, gross vehicle weight, radius of operation, prior carrier and loss history. A US broker booking forty trucking risks a month is doing the same transcription dance, just with a different form family. The same Mezdoc template engine runs that workflow with the ACORD form on top instead of the Indian motor proposal. The shared field vocabulary (insured name, address, vehicle id, sum insured / coverage limit) is what makes the same plumbing serve both markets.

A practical starting point

If you are a broker handling a hundred cases a month and you want to try this:

• Pick the form you fill most often. Probably the private car proposal.
• Upload the insurer-provided PDF into a Mezdoc template.
• Drop fields on it. Aliases match the keys you already use in your CRM.
• Publish to staging, run five test submissions with real customer data you control.
• Wire a webhook from your CRM. POST on policy creation, file the response PDF.

Two days of work. After that, every car policy your team books just produces its proposal PDF as a side effect. The associate who used to type the form now has time to talk to customers.

That is the real change. Not faster typing. No more typing.