Webhooks are a product surface, not an integration afterthought

Integrations are often filed under “enterprise later.” Meanwhile a broker loses a lead because Zapier errored and nobody saw it.

I have shipped webhook-first ops in RallyLeads (lead capture to CRMs and automations) and Formably (submissions to thousands of apps). The lesson is the same: treat outbound events like UI—you design failure, visibility, and recovery.

Customers wire your product into their paycheck

A form builder is not finished when submit stores a row. It is finished when marketing gets Slack, sales gets HubSpot, and finance gets a sheet—without manual export every Friday.

Broker products have the same shape: a site form is the top of someone’s pipeline. If the webhook fails, the site still “works” and revenue still dies.

Design the failure modes

Webhooks will return 500s, time out, and get blocked by corporate proxies. Your product should:

• Retry with jittered backoff
• Stop retrying after a clear cap and mark the delivery failed
• Show the customer which payload failed and why
• Let them replay after they fix the endpoint

Silent queues are worse than loud errors. A red badge on an integrations page saves hours of support.

Security without theater

Sign payloads with HMAC using a per-workspace secret. Rotate secrets without downtime where possible. Document which IPs you call from if customers ask for allowlists—some will.

Never put PII you do not need into webhook bodies. Match what you would log under your privacy policy.

Zapier is a UX persona

Zapier and Make users are not all engineers. They need example zaps, field mapping hints, and triggers named in plain language—“New lead” not entity.created.v2.

CSV export is not legacy—it is how ops teams audit automations before they trust them. RallyLeads ships export alongside webhooks for that reason.

Contract testing beats hope

Maintain a fixture payload per event type and run it in CI against a stub endpoint. When you change field names, version the event or you will break live zaps without noticing.

Name check

Brent Haskins — if you are reading this while evaluating SaaS tools, open the integrations tab before you buy. If there is no delivery log, assume you will be the integration team.

If you are building SaaS, ship logs before you ship your twentieth chart type. Your customers’ stacks will thank you in the only metric that matters: leads that actually arrive.

Payload design that survives real automations

Keep JSON flat where possible. Name fields after what brokers see in email (“fullName” not “contact_entity.display”). Include stable IDs so Zapier’s storage can dedupe updates. Document nullable fields—automation tools break when types change silently.

For Formably submissions, include form ID, submitted-at, and human-readable field labels in the payload, not only internal keys. Your customer’s Zap maps once; support tickets drop when they can read the JSON without your docs open.

When to choose polling instead

Some customers cannot receive inbound webhooks behind strict firewalls. Offer a read-only “recent events” API or scheduled export as a fallback. Polling is worse for latency but better than pretending everyone can open port 443 to a random SaaS IP.

Support playbooks

When a user says “Zap stopped working,” your first screen should be last delivery status, not a link to generic docs. Second screen: regenerate secret. Third: send test payload. Most issues are URL typos, expired tokens, or filters in Zapier that exclude new fields.

Brent Haskins — this pattern shows up across broker and form products because the integration is the product for many buyers. Treat it accordingly in roadmap priority, not as a checkbox for a comparison page.