send.webforms.toRead the docs →

productengineering

We could have shipped 40 more integrations. We shipped routing rules instead.

A longer integration list is an easy feature to announce and a genuinely weak one to actually use. Here's what we built instead and why.

WebForms6 min read

It's an easy pitch: "we integrate with 60 tools" reads well on a comparison page, and building the sixtieth webhook-shaped integration is genuinely not that hard once you've built the first ten. We chose not to spend our time that way, and it's worth explaining the actual reasoning rather than the marketing version of it.

What a longer integration list actually buys you

Almost nothing, past a certain point, if every integration behaves identically once configured: a submission comes in, it goes to every destination you've turned on, every time, with no way to say "this one only if the plan field says Enterprise" or "skip Slack for anything that looks like spam but keep the email." At that point the integration count is measuring surface area, not capability. Five destinations with routing between them is a more useful product than fifty destinations without it.

The actual problem people have

Talk to anyone running more than one form and the complaint isn't "I wish you supported tool number 61." It's some version of: "our sales team gets pinged on Slack for every single contact form submission, including the ones that are obviously spam, and now people have muted the channel, which means they also miss the real leads." Or: "I want enterprise-tier leads to hit our CRM immediately and go to a Slack channel our AEs actually watch, but free-tier signups can just land in the database, nobody needs a notification for those." That's not a missing integration. That's a missing decision layer sitting between "a submission arrived" and "here's where it goes."

What we built instead

Routing rules: conditions on a submission's field values that decide which destinations actually fire for that specific submission, evaluated before fan-out rather than as an afterthought bolted onto delivery. "If plan equals Enterprise, send to CRM webhook and #enterprise-leads. Otherwise, store it and send the confirmation email, nothing else." One form, multiple behaviors, depending on what was actually submitted.

Paired with that: a delivery log per destination per submission, not just per submission. "Did the email send" and "did the webhook fire" and "did Slack get it" are three different questions with three different possible failure modes, and a support conversation that starts with "I never got notified" is unanswerable without being able to see, per destination, what was attempted, what came back, and whether it retried. A longer integration list makes that conversation worse, not better - more places something could have silently failed, with no more visibility into any of them.

The tradeoff we accepted

We do have fewer native destinations than some competitors, and we're not going to pretend that's free. If you specifically need a form to write straight into a spreadsheet product we don't build a native connector for, a webhook plus an automation platform in between is an extra hop you wouldn't need with a service that has that connector built in. That's a real gap for a real subset of people, and the honest answer is: use a webhook for now, or tell us and we'll consider building it.

What we're not willing to trade is routing and delivery visibility for a longer logo wall. Those compound in value as you add forms and destinations; a longer integration list mostly just gets longer.

Get your endpoint

Free for 300 submissions a month. No card required.

Start free