How to send insurance calculator leads into HighLevel with an inbound webhook

A calculator lead is only valuable if it reaches the person who will call it, with the numbers intact. For agencies that run their follow-up in HighLevel, that means the lead should arrive as a contact, carry the calculator's inputs and results in fields a producer can read, get the right tags, land in the right pipeline stage, and trigger the right first touch — all without anyone copying data from an email. This guide walks through that setup in the order you would actually build it.

A note on what this is: the connection is a webhook. InsuranceQuoteWidget sends each lead as JSON to a URL, and HighLevel's inbound webhook workflow trigger receives it. HighLevel's interface changes from time to time, so menu names below are described generally; follow the labels in your own account.

How does a calculator lead get from your website into HighLevel?

When a visitor submits a calculator, InsuranceQuoteWidget saves the lead, emails your agency if alerts are on, and POSTs the lead as JSON to your webhook URL. In HighLevel, a workflow that starts with the inbound webhook trigger receives that JSON, and the steps that follow create or update the contact, tag it and place it in a pipeline.

The flow, end to end:

1. Visitor works out their estimate in a calculator on your site and submits the lead form with consent.
2. The lead is stored in your built-in contacts list, de-duplicated by email and then phone.
3. The JSON payload is POSTed to the calculator's own webhook if it has one, otherwise to your agency-wide webhook.
4. HighLevel's inbound webhook trigger starts the workflow.
5. Workflow actions map the data to a contact, apply tags, create or move an opportunity, and start the first-touch sequence.

Because the payload is plain JSON over HTTPS, the same setup also works with Zapier, Make or any endpoint you control. The HighLevel CRM sync feature page summarizes the options.

What is in the webhook payload?

Each payload identifies the event and the calculator, says whether the contact is new, and carries the contact details, the submission (the visitor's inputs and the calculator's results), the submission time and campaign attribution. Attribution appears both nested and as flat fields for easy mapping.

The exact input and result names depend on the calculator. For the life insurance calculator, the inputs include Annual Income, Mortgage Balance and Existing Life Insurance, and the results include Recommended Coverage and Less: Existing Resources. For the disability insurance calculator, results include Additional Coverage Needed and Target Monthly Benefit. Map the two or three values a producer reads first; keep the rest in a note.

How do you set up the inbound webhook trigger?

Create a new workflow in HighLevel, choose the inbound webhook trigger, and copy the URL it generates. Paste that URL into the calculator's webhook setting, or your agency-wide webhook. Then submit one real test lead so HighLevel captures a sample payload, select that sample in the trigger, and save.

Step by step:

1. Create the workflow. In HighLevel's automation area, start a new workflow from scratch. Name it after the line or calculator, for example "Calculator lead: life".
2. Add the trigger. Choose the inbound webhook trigger. HighLevel generates a unique URL for this workflow. HighLevel classes this as a premium trigger, which may carry usage charges depending on your account; check your billing settings.
3. Paste the URL into InsuranceQuoteWidget. Add it as the calculator's webhook if this workflow is for one calculator, or as the agency-wide webhook if it should catch everything without its own setting.
4. Send a real test. Open the calculator on a test page, enter realistic numbers and submit with a test email you control. Default values make poor test data because they hide mapping mistakes.
5. Capture the sample. Back in the trigger, fetch or select the sample request HighLevel received. This gives you the field picker for later steps.
6. Save the trigger and leave the workflow in draft until mapping is done.

If no sample appears, check that the URL was pasted completely, that the test submission succeeded, and that your plan includes webhooks (Agency and Enterprise do).

How should you map calculator fields to HighLevel contacts?

Map identity to standard contact fields, the two or three most decision-relevant results to custom fields, attribution to its own custom fields, and the full submission to a note. Use HighLevel's create-or-update style contact action keyed on email or phone, so a returning visitor updates their record instead of duplicating it.

Recommended mapping by audience

Think about who reads each field:

• Producers need the result and the inputs that explain it. For life: Recommended Coverage, Annual Income, Existing Life Insurance, Mortgage Balance. For annuities: Initial Premium and Years to Grow from the fixed annuity calculator. For long-term care: Funding Gap and Years Until Care Needed from the long-term care calculator.
• Marketers need attribution: UTM source, medium and campaign, click IDs, landing page and first-touch source.
• Compliance needs the submission time, page URL and consent state, plus the version of consent text in use.

Naming custom fields so they survive growth

Prefix calculator fields by line, for example life_recommended_coverage, di_additional_coverage_needed, ltc_funding_gap. When you add more calculators later, the fields stay grouped and nobody overwrites a life value with an annuity value. Create number fields for currency results so you can filter on them.

Notes beat field sprawl

Not every input deserves a custom field. Write a note on the contact containing every input and result from the submission, formatted as "Label: value" lines. Producers read notes; reports read fields. That split keeps your HighLevel account tidy.

How should you use tags and pipeline stages?

Use tags to describe what a lead is and pipeline stages to describe where the conversation stands. Tags such as line, calculator, language and triage band are permanent facts; stages such as new, contacted, needs review and proposal are temporary positions. Mixing the two produces filters nobody trusts.

A simple triage rule set

Add an if/else step after mapping. Rules might look like:

• If the life result shows a large gap relative to existing coverage, and a phone is present, tag band-a.
• If the inputs equal the calculator defaults, tag band-c for an email-first approach.
• If is_new_contact is false, tag repeat-calculator and notify the contact's existing owner instead of round-robin assignment.

The thresholds are your agency's decision. Our field guide to pre-qualifying insurance leads explains a four-band approach.

Pipelines per line, not per calculator

Create one pipeline per line you sell (life, health, Medicare, annuities) rather than one per calculator. The disability insurance and human life value calculators feed the same protection conversation, so they belong in the same pipeline with different tags.

Where does consent fit in the workflow?

Put a consent and suppression check immediately after mapping and before any call, text or marketing email step. If the contact has opted out through any channel, or the submission lacks the consent your outreach method requires, route to a manual-review branch instead of the automated sequence.

This matters more since the FCC's revocation rules took effect on April 11, 2025, under which consumers may revoke consent by any reasonable means and revocations must be honored within 10 business days. A separate revoke-all provision, delayed to January 31, 2027, would extend one revocation across unrelated messages. A single suppression field checked at the top of every HighLevel workflow prepares you for both. See our TCPA consent guide, the lead consent page and the compliance overview. None of this is legal advice.

Line-specific rules belong in the workflow too. A Medicare-related branch should respect CMS marketing rules, including scope-of-appointment requirements; an annuity branch should hand off to a licensed producer for a suitability conversation rather than sending product pitches automatically.

What should the first automated touch say?

The first touch should confirm the request, restate the visitor's estimate as an estimate, name the producer who will follow up, and offer a time. It should not promise savings, approval or a price. Keep it short, and send it only to contacts that pass the consent check.

An example for a life lead, adapted to your own voice:

Thanks for running the life insurance estimate on our site. Your result suggested coverage of about {life_recommended_coverage}, based on the numbers you entered. That's an estimate, not a quote — a licensed agent here can check the assumptions with you. Reply with a good time, or book here.

Use merge fields from your mapped custom fields, and keep the "estimate, not a quote" language.

How do you test the whole workflow before going live?

Run four test submissions: a new contact with strong numbers, a new contact with default values, a returning contact, and a contact that has opted out. Confirm each one creates or updates the right record, gets the right tags and stage, and either triggers or skips outreach correctly.

Go-live checklist

1. Webhook URL pasted into the right calculator or agency-wide setting.
2. Sample payload captured from a realistic test submission.
3. Contact action set to create-or-update on email, then phone.
4. Two to four results mapped to prefixed custom fields; full submission written to a note.
5. Attribution fields mapped, including first-touch source and click IDs.
6. Tags for line, calculator and band applied; one pipeline per line.
7. Consent and suppression check placed before any outreach step.
8. First-touch message says "estimate", names a licensed producer and makes no promises.
9. Four test scenarios passed: strong, default, returning, opted-out.
10. Someone owns the over-limit email alert, so unsaved leads are noticed.

What about agencies that don't use HighLevel?

Every lead also lands in the built-in contacts list with notes and statuses, and can trigger an email alert. If your CRM is elsewhere, point the webhook at Zapier, Make or any HTTPS endpoint instead. The payload is identical, so the mapping advice above still applies.

The agency CRM page covers the built-in contacts list, and lead attribution explains the campaign data. Webhooks are available on the Agency and Enterprise plans, and the insurance calculators are part of the Enterprise plan today; compare plans for details.

InsuranceQuoteWidget is software, not an insurance agency or producer, and does not quote, sell or bind insurance. Calculator results are estimates. Licensing varies by state.