Quickstart A — Receive policy data via webhook
What you'll build: a small web server that receives extracted policy data from InsurGrid, verifies it's genuine, and prints it. By the end you'll have handled a real (test) policy-data webhook end to end.
Time: ~20 minutes.
Prerequisites (from Get started):
Step 1 — Get your signing secret
From the dashboard's API section, copy your signing secret and put it in an environment variable so it never lands in your code:
export INSURGRID_SIGNING_SECRET="whsec_...your secret..."You'll use it in Step 4 to prove each webhook really came from InsurGrid.
Step 2 — Stand up an endpoint · server
Create a tiny server with one route that accepts a POST. Read the raw request body as well as the parsed JSON — you need the raw bytes for signature verification in Step 4.
Node (Express):
// server.js — run with: node server.js
const express = require("express");
const app = express();
// Keep the raw body; we need the exact bytes to verify the signature.
app.use(express.json({
verify: (req, _res, buf) => { req.rawBody = buf; },
}));
app.post("/hooks/insurgrid", (req, res) => {
res.sendStatus(200); // Step 3: acknowledge fast
console.log("Received:", req.body.topic);
// signature check + processing come next
});
app.listen(3000, () => console.log("Listening on :3000"));Python (Flask):
Step 3 — Acknowledge fast, process later
Notice both handlers return 200 right away. Do any slow work (saving to your DB, calling other services) after you respond — see Set up a webhook endpoint for why this matters. For this quickstart, printing is enough.
Step 4 — Expose your endpoint & register it · local dev
If you're on your machine, start a tunnel so InsurGrid can reach you:
Copy the https://… URL it prints, append /hooks/insurgrid, and add it in the dashboard's API section as the staging URL for the client-submission topic. (Full walkthrough: Expose your local endpoint.)
Step 5 — Verify the signature · server
Every webhook carries an x-signature header: an HMAC-SHA256 of the raw request body, computed with your signing secret. Recompute it on your side and compare — if it doesn't match, reject the request.
New term — HMAC signature: a fingerprint of the message made with a shared secret. Because only you and InsurGrid know the secret, a matching fingerprint proves the message is genuine and unaltered. Compute it over the exact raw bytes you received — if you re-serialize the parsed JSON first, the bytes differ and the check will falsely fail. This is the #1 first-timer bug.
Node:
Python:
Prefer a different scheme (Bearer token, Basic auth, or an API-key header) instead of a signature? You can configure that per endpoint — see Register your endpoint & choose an auth type.
Step 6 — Read the payload · server
A verified policy-data webhook looks like this:
Key fields:
topic
string
The event type. For policy data it's client-submission.
"client-submission"
data.document_link
string (URL)
A time-limited link to the source declaration-page file.
"https://files.insurgrid.com/…"
data.policy_type
string
A descriptive label for the insurance line — a hint, not a fixed code (don't hard-match).
"Personal Auto", "Homeowners"
data.*
object/array
The extracted policy fields. The set depends on policy_type.
see Webhook events & payloads
⚠️
document_linkexpires. It's a temporary download link. If you need the file, fetch and store it on your side promptly — don't save the link and expect it to work later.
The full field list per policy type is in the Webhook events & payloads reference.
Step 7 — De-duplicate · server
Delivery is at-least-once: the same event may occasionally arrive more than once (for example, if a retry overlaps a slow success). So make your handler idempotent — processing the same event twice must be harmless.
The policy-data payload has no dedicated event-id field, so de-duplicate on a hash of the payload contents — identical content means it's the same event. Record hashes you've already handled and skip repeats:
See Delivery & de-duplication for patterns. (The form-submission event is simpler — it carries a submission_id you can key on directly.)
Step 8 — Try it out (sandbox)
In the API section, use Send test event to fire a sample
client-submissionat your staging URL.Watch your server log the topic and the payload.
Check the delivery log in the dashboard — you'll see the attempt and your
200response.
If nothing arrives, jump to Troubleshooting → "My webhook isn't arriving".
Step 9 — Go live
When staging works end to end:
Deploy your endpoint to a real HTTPS URL.
Add that URL as your production
client-submissionwebhook.Switch to your production signing secret and API token.
Run the Integration checklist.
Next steps
Webhook events & payloads (all fields) →
Verify signatures — deeper dive →
