Quotify
Start free
INTEGRATIONS

Webhooks: setup, retries, and the delivery log

· 7 min

Every Quotify form can post each submission to a URL of your choice. That’s what a webhook is. This article covers the practical bits: where to add one, what the payload looks like, how retries work, and how to read the delivery log when you need to debug.

For the why (and the story of why retries and the log exist at all) see the companion piece: Your Zap fails silently. Here’s how Quotify finally tells you.

Where to set webhooks up

  1. Open the form in Quotify.
  2. Go to Integrations.
  3. Paste your destination URL into the Webhook URL field and save.

From the moment you save, every new submission for that form will be posted to that URL.

What the payload looks like

The payload is JSON. It includes the form’s submission metadata, the answers to each question, the customer’s contact details, and source attribution (which landing page, which referrer). It’s not pre-shaped for any particular platform; whichever tool you point it at will see a normal JSON object and map fields from there.

The quickest way to see the exact shape your form will send is to:

  1. Paste any test URL into the Webhook URL field (a free webhook.site inspector is perfect for this: it gives you a one-off URL to inspect what came in).
  2. Submit a test entry on the form.
  3. Inspect the request body at the test URL.

You can then plug the real URL in once you know what your downstream tool needs to consume.

Where you can point the webhook

Three common destinations, in roughly increasing order of effort:

  • Zapier uses a Catch Hook trigger; Zapier auto-detects your fields after a test submission. Walkthrough below.
  • Make.com uses a Custom webhook trigger; identical pattern to Zapier, slightly more generous free tier. Walkthrough below.
  • Your own endpoint: anything that accepts a POST and parses JSON. Notes below.

All three flow through the same retry and logging behaviour. The platform you pick doesn’t change the delivery guarantees.

How retries work

If a delivery fails (meaning the destination returns a non-2xx status code, or the request times out) Quotify automatically retries it once, about a second later. That second attempt clears the genuinely momentary blips: a redeploy that finished half a second ago, a connection that dropped once.

If the retry also fails, Quotify stops and marks the delivery as failed. The delivery log records both attempts, including the failure, so nothing disappears quietly. The log, not the retry, is the real safety net here: it’s what turns a silent failure into one you can see and act on.

A few things worth knowing:

  • 2xx = success. Anything in the 200–299 range counts as delivered. We don’t try to parse the response body — if the server said “OK”, we believe it.
  • 3xx = success. Redirects are followed automatically. The final destination’s response is what counts.
  • 4xx = client error, doesn’t retry. A 400 or 401 means we sent something wrong (or your endpoint rejected the auth). Retrying won’t help, so we don’t, but we do log it so you can see what came back.
  • 5xx and timeouts = retried once. Server errors and timeouts are the cases where a quick second attempt can help, so those get the retry.
  • 429 = retried once. Rate limits get one retry too, but a sustained rate-limit (Zapier’s free tier under a burst) will outlast a one-second retry, so the delivery log is where you’ll spot those.

Reading the delivery log

Every form has a Recent deliveries panel under Integrations. For each delivery you’ll see:

  • Status: HTTP status code from the final attempt
  • Retries: how many attempts it took (1/2 means it went through first try; 2/2 means the retry was needed; 2/2 failed means both attempts failed)
  • Duration: how long the successful request took
  • When: relative time since the delivery

Click any row to see the full request and response details: the headers we sent, the body we posted, and what the server returned. This is the panel to live in when something’s not behaving.

Common things you’ll see and what they mean

StatusWhat it meansWhat to do
200 OK (1/2)Delivered first tryNothing, working as intended
200 OK (2/2)Needed the retry, then workedUsually fine. If you see lots of these, the endpoint is flaky
401 Unauthorized (1/2)Your endpoint rejected the authCheck your endpoint’s auth requirements
404 Not Found (1/2)URL doesn’t existRecheck the URL, typo most likely
429 Too Many Requests (2/2 failed)Rate-limited past the retryUpgrade the destination plan, or batch differently
500 Internal Server Error (2/2 failed)Destination is brokenCheck the destination service’s status page / logs
Timeout (2/2 failed)Destination didn’t respond in timeCheck destination is reachable; consider a faster endpoint

Setting up with Zapier

  1. In Zapier, create a new Zap and pick Webhooks by Zapier → Catch Hook as the trigger.
  2. Zapier gives you a URL like https://hooks.zapier.com/hooks/catch/.... Copy it.
  3. In Quotify → form → Integrations, paste the URL into Webhook URL and save.
  4. Back in Zapier, click Test trigger then submit a test entry to your form. Zapier will pick up the submission and all your form fields will appear in the picker for the next step.
  5. Build the rest of your Zap as normal.

Heads up: Zapier’s free plan rate-limits webhooks. If you see a lot of 429 responses in the delivery log, that’s why. The automatic retry catches the odd one-off, but a sustained burst (a paid ad campaign sending submissions faster than the free Zap can drain) will keep hitting the limit, so the delivery log is where you’ll catch it.

Setting up with Make.com

Make.com (formerly Integromat) consumes the webhook the same way Zapier does. Its HTTP / Webhooks modules will happily parse the JSON Quotify sends.

  1. In Make.com, create a new scenario and add a Webhooks → Custom webhook trigger.
  2. Click Add to create a new webhook. Give it a name and Make gives you a URL like https://hook.eu1.make.com/.... Copy it.
  3. In Quotify → form → Integrations, paste the URL into Webhook URL and save.
  4. Back in Make.com, click Re-determine data structure, then submit a test entry to your Quotify form. Make.com will receive the payload and auto-detect the field structure.
  5. Build the rest of your scenario.

Make.com’s free tier is more generous on operations than Zapier’s, so rate-limit retries are rarely an issue here.

Setting up your own endpoint

If you’re rolling a custom integration, point the Webhook URL at your endpoint and you’re done. A few practical notes:

  • Respond fast. Aim to return a 2xx within a couple of seconds. If you need to do heavy work, accept the payload and process it asynchronously.
  • Be idempotent. Each submission carries its own unique identifier in the payload; use it as a dedupe key. A retry could in theory arrive after your endpoint did process the previous attempt but failed to respond in time; designing around the submission ID makes that harmless.
  • Verify the source if it matters. The webhook is fired from Quotify’s infrastructure; if you need stronger guarantees than “the URL is hard to guess”, reach out and we’ll discuss signing.

Troubleshooting checklist

  • Nothing arriving? Check the delivery log under the form’s Integrations tab. If there are no entries at all, the webhook URL isn’t saved: check you hit Save after pasting it.
  • Deliveries showing as failed? Click into a failed delivery for the full response. The status code + response body usually tell you what the destination is complaining about.
  • Lots of 429s? Rate-limited. Upgrade the destination plan, or move the destination to a tool with a higher limit (Make.com is generous here).
  • Got 500s from your own endpoint? Check your server logs. The delivery log shows what we sent; your logs will show why your code didn’t like it.
  • Working in test but not in production? Some platforms (notably Zapier) have separate webhook URLs per environment. Make sure the URL you’ve pasted into Quotify is the live one, not the test one.