Diagnosed and fixed a broken lead-delivery pipeline between a Webflow form and a third-party CRM's strict email-parser API — isolating the failure point through systematic testing rather than guesswork, then rebuilding via direct API calls when the UI proved unreliable.
Stack: Webflow (Form Webhooks) · Make.com · Gmail API · Property Shell CRM (Lead Mailbox) · webhook.site
A client's CRM (Property Shell, via its "Lead Mailbox" module) accepts new leads through an email parser — but only if the email body matches a strict XML tag format:
<property_shell_lead>
<first_name>...</first_name>
<last_name>...</last_name>
...
</property_shell_lead>Webflow's native Email Notifications can't produce this. The Body field only supports four system variables ({{siteName}}, {{formName}}, {{formData}}, {{formDashboardUrl}}) — individual field merge-tags like {{First-name}} appear valid in the editor UI but silently fail to resolve at send time. There's no native way to shape form data into a custom structured format.
Bypass Webflow's notification system entirely: route form submissions through a webhook into an automation platform that can construct the exact XML payload the CRM expects.
Webflow Form Submit → Webhook → Make.com → Gmail (Raw HTML, XML body) → CRM Lead Mailbox
- A Custom Webhook is registered in Webflow (Form submission trigger, API V2)
- Make.com receives the payload and maps individual form fields into the required XML structure
- A Gmail module sends the constructed XML as a raw HTML email to the CRM's parser address
- The CRM parses the XML and creates the lead
Gmail's Raw HTML mode interprets angle brackets as markup, which silently strips unescaped XML tags. The fix: encode every < and > as HTML entities (< / >) so the tags survive transmission as literal text and only resolve to angle brackets on the receiving end.
When the pipeline produced no visible errors — form submitted, no email arrived — the first move was to remove ambiguity about which side was failing. Pointing the Webflow webhook at webhook.site confirmed Webflow was sending a complete, correctly-signed JSON payload (with x-webflow-signature and full form data) instantly and reliably. That isolated the fault to the Make.com ↔ CRM leg of the pipeline — ruling out an entire category of possible causes before touching any configuration.
Make's dashboard showed no errors, no incomplete executions, nothing actionable — a dead end that would normally mean guessing. Calling Make's API directly (hooks_ping) surfaced a state the UI didn't expose clearly. Rather than trust an ambiguous signal, the webhook and scenario were rebuilt from scratch via API (hooks_create + scenarios_update with a fresh hookId) instead of trying to patch a connection whose actual state couldn't be confirmed through the interface. The rebuilt pipeline worked on the first test.
- Fully functional lead pipeline: Webflow form → correctly formatted CRM entry, verified end-to-end with a live test submission (correct subject line, both recipients, all fields intact)
- Client confirmation from the CRM provider's team: "Confirming the CRM now works – nice work."
- Systematic debugging under ambiguity: isolating a silent failure via a neutral test endpoint before touching either side of the integration
- Working below the UI layer: using API calls to get ground-truth state when the dashboard couldn't be trusted
- Cross-system integration: shaping data to match a rigid third-party format (strict XML-over-email) using no-code/low-code tooling
- Comfort troubleshooting production issues under a client deadline, not just building from a spec
Built by Val Mazur — Webflow Certified Partner, M.Sc. Computer Science. I build AI-augmented web systems: Webflow front-ends, data/logic layers, and system integrations.