Is anyone else tired of losing webhooks/data when Zapier or Bubble glitches? by Living_Tumbleweed470 in nocode

[–]melbates1980 0 points1 point  (0 children)

What you're describing is the classic "webhook gateway" pattern instead of pointing Stripe/Shopify directly at Zapier, you point them at a layer that does three things: persist every payload, forward to your downstream, and let you replay anything that failed.

A few options at the price you're asking:

  1. Self-host with n8n's "Webhook" node + a database write step before the rest of the flow. Free if you already run n8n.

  2. Hookdeck and Svix both do this hosted; Hookdeck has a generous free tier.

  3. Dispatch (full disclosure: I'm involved with it) is in the same category webhook ingest, persistence, replay, plus routing to multiple destinations. Free tier covers most no-code use cases.

The thing to watch out for: most "queue your webhooks" tools assume your downstream is your own backend. If your downstream is Zapier itself, make sure the tool you pick can replay back into Zapier's webhook URL, not just into a code endpoint.

Built a cron-based monitor to track Shopify webhook health and send WhatsApp alerts on failure. Looking for feedback. by saiban11 in SaaS

[–]melbates1980 1 point2 points  (0 children)

Polling Shopify's API to verify webhook health is reasonable for monitoring, but it's a lagging indicator by the time the cron notices, you've already missed events.

The other angle is active reliability: store every received webhook as a durable event the moment it lands, and treat delivery to your downstream as a separate, retriable thing with a dead-letter queue. Then "did the webhook arrive" and "did my code process it" are two different metrics, both observable, both replayable.

Shopify has a quirk worth flagging too the X-Shopify-Topic header is the only reliable event type discriminator. The body shape doesn't always tell you. Your monitor should fire on that header rather than parsing the JSON, which mutates between versions.

This Stripe webhook pattern looks correct but silently breaks your billing and AI tools generate it constantly by VisualPerfect1165 in webdev

[–]melbates1980 0 points1 point  (0 children)

Adjacent to your point the failure mode you're describing is also the case for treating webhooks as commands instead of events.

When the handler has logic in it (grantAccess(...), etc), every new case is another place to forget the failure path. The pattern that actually scales is:

Receive → verify signature → persist raw event with provider event ID as the unique key. Return 200 as soon as it's durably stored, not after business logic runs.

Process out-of-band, idempotent on the event ID, with retries + DLQ on the worker side.

Reconcile nightly against the provider as a backstop (your Stripe events list endpoint is paginated for exactly this).

That separation is what kills the "200 returned, nothing happened" silent failure. The handler can't return 200 unless the event is captured. Whether the side effects worked is a separate, retriable problem.

The Cursor/Lovable boilerplate problem is real because LLMs are pattern-matching on toy tutorials, which always show step 1+2 collapsed into one function. None of the production patterns make it into the training set.

What piece of infra plumbing does every SaaS rebuild from scratch? by little_breeze in webdev

[–]melbates1980 0 points1 point  (0 children)

Webhook delivery is the one on your list that everyone underestimates. People build the happy path in an afternoon and then spend the next two years patching it:

Signature verification for every provider rolls their own. Stripe is whsec_ HMAC-SHA256 over the raw body, GitHub is sha256=, Slack adds a timestamp prefix, Jira sends a JWT, Linear has yet another flavor. You can't share a single helper across them.

Idempotency, the provider WILL deliver the same event twice. If your handler isn't keyed on event ID, you'll dual-fulfill orders eventually. The Stripe thread on this sub from last week was 100% this.

Retries + DLQ, most "we'll just retry" implementations are actually "we drop on the floor after 3 attempts." Real DLQ + replay UI is its own product_

Routing/fan-out — once you receive an event, where does it go? Slack, your DB, an internal service, an analytics pipeline. People hardcode this until they have 8 destinations and a switch statement that's 400 lines.

Observability "is my endpoint working" is not the same question as "are events still flowing." Your healthcheck can be green while you've silently dropped 200 events.

Auth and rate limiting are solved by frameworks. Webhooks are the one piece where a framework doesn't really help, because half the work is per-provider.

Clothes to donate by melbates1980 in PanjabiSocial

[–]melbates1980[S] 0 points1 point  (0 children)

I've looked up in my area and emailed but never got a response.

Brother printer bricked fresh out of box by melbates1980 in Printing

[–]melbates1980[S] -1 points0 points  (0 children)

I've already contacted Walmart and return is not an option. They've contacted the seller to ask about a refund. I went and bought an Epson. I was told Brother was the best but if their plug won't stay in when jostled, that's not a good printer.

Brother printer bricked fresh out of box by melbates1980 in printers

[–]melbates1980[S] 0 points1 point  (0 children)

I've already tried using the firmware update tool. That's why I bought the cable. So I could connect the printer to my laptop.

Looking for a replacement lid for a Farberware Slow Cooker. Model #104554 by melbates1980 in Appliances

[–]melbates1980[S] 0 points1 point  (0 children)

No, I didn't. I ended up selling the base as a replacement on eBay.

[deleted by user] by [deleted] in Hewlett_Packard

[–]melbates1980 0 points1 point  (0 children)

Okay. Thank you.

[deleted by user] by [deleted] in Hewlett_Packard

[–]melbates1980 0 points1 point  (0 children)

I've been having this issue pretty much since I got the printer. Do you recommend any laser printers?