Picture this. You set up a quote form in Quotify. You wire it into Zapier so every submission lands in a Google Sheet, fires a Slack message to your sales channel, and adds the lead to a Mailchimp audience. You test it. The Zap fires, the row appears, the Slack ping arrives. You close the laptop.
Two weeks later a customer phones up furious. They filled in the form, never heard back, gave the job to someone else, and now you’ve cost yourself the work and the goodwill. You check the inbox: no notification email. You check the Sheet: no row. You check Slack: nothing. The submission is there in Quotify. The Zap shows a failed run at 02:14 on a Wednesday. Rate-limited. Never retried.
This is the silent-failure problem with webhooks, and it’s not unique to Zapier. It happens any time you wire two systems together over HTTP. One end posts. The other end has a bad afternoon. The first end shrugs and moves on.
The new webhook system in Quotify is built so that doesn’t happen to you anymore. Two things changed, and they’re the difference between “wired up” and “I trust this in production.”
1. Webhooks now retry
A webhook is just an HTTP POST. Quotify sends your submission to a URL you specify, the URL responds, life goes on. The problem is “life goes on” includes the times the URL didn’t respond, or responded with a 500, or timed out, or returned a 429 because Zapier’s having a moment.
The old behaviour was: one shot, log the result, move on. Which is fine 99% of the time. It’s that 1% — the rate-limited, the deploying-right-now, the briefly-down — that quietly eats your leads.
The new behaviour: if a delivery fails (any non-2xx response, or a timeout), Quotify automatically retries it once, a second or so later. That catches the genuinely momentary stuff: a redeploy that just finished, a connection that dropped once. If the retry fails too, we stop and flag the delivery as failed so you can see it and react, rather than letting it vanish.
The point isn’t that webhooks now never fail. They will. Servers go down. Zaps get paused. The point is that the momentary failures (a brief blip, a deploy that just finished) get a second chance without you ever knowing. And everything else, the real failures and the stubborn rate-limits, gets surfaced in the log instead of buried.
2. There’s a log of every attempt
Open any form in Quotify, head to the Integrations tab, and there’s a Recent deliveries panel. Every webhook attempt for the last while is listed there: status code, retry pill (so you can see at a glance whether it went first time or needed the retry), how long the request took, and how long ago it happened.
If a delivery failed, you can see why. If it went through on the retry, you can see that too, useful when you’re debugging a flaky downstream system.
This is the thing that turns webhooks from “I hope it’s working” into something you can actually trust. Because trust isn’t about things never failing. It’s about being able to see when they did.
One URL, any platform
The webhook itself is deliberately unopinionated. One URL field, one JSON payload. It’s not pre-shaped for any particular tool. It just sends the submission, and the tool at the other end decides what to do with it.
That means you can point it wherever you want:
- Zapier: create a Catch Hook trigger, paste the Zapier URL into Quotify, fire a test submission, and Zapier maps your form fields automatically.
- Make.com: same pattern. Custom webhook trigger, paste the URL, test, map.
- Your own endpoint: accept the POST, parse the JSON, do whatever your stack does next.
All three flow through the same retry + logging pipeline. The platform you pick doesn’t change the delivery guarantees or the visibility. That’s the part Quotify owns. The mapping happens at the other end, where it belongs.
(Step-by-step setup for each of those is in the webhooks KB article.)
Why this matters more than it sounds
If you’ve never been bitten by a silently-failing webhook, this whole post probably reads as overkill. “Cool, the platform does retries. Sure.” The reason I’m making a thing of it: webhook failures don’t look like bugs. They look like ghosting.
The customer fills in the form. From their side, everything happens: confirmation page, “we’ll be in touch”, maybe even an email back. Quotify did its job. The submission is captured. But the system you actually run your day in (your CRM, your inbox, your booking calendar, whatever sits at the end of that Zap) never got the news. So nobody chases. And nobody knows nobody chased, because nothing visibly broke.
You only find out when the customer follows up. Or, more often, when they don’t, and you never know they were there.
A retrying webhook with a visible delivery log is the unglamorous piece of infrastructure that makes the difference between “we got the lead but missed the moment” and “we got the lead, full stop.” Same form. Same Zap. Same downstream tools. Just a layer in the middle that doesn’t quietly give up.
What to do with it
If you’ve already got a webhook configured: there’s nothing to change. The retries and the log are on for everyone, so go and have a look at Recent deliveries under any form’s Integrations tab and see what’s been happening over the last few weeks.
If you haven’t connected anything yet, this is a good week to. The Zapier and Make.com flows are both about 5 minutes end-to-end, and you’d be wiring it into a system that now tells you when something goes wrong instead of leaving you to find out the hard way.
The full setup walkthrough (Zapier, Make.com, custom endpoints, what each status code means in the delivery log) lives in the webhooks KB article.
This piece is one of the five things in the bigger update that shipped last month. If you’ve been meaning to revisit Quotify, the others (branded PDFs, the lead inbox, landing pages, the analytics rebuild) are all worth a look while you’re in there.