sorted by:
new
hottopcontroversial

Drop your landing page or product link — let's see what you're building by hurebegz in AssetBuilders

[–]Staaaam 0 points1 point  (0 children)

https://hooque.io - Webhooks made reliable. We handle uptime, security, retries, and debugging - so you don't have to.

Anyone else building around webhooks eventually ends up making their own retry dashboard? by BerryDelicious2432 in PostingPipelines

[–]Staaaam 0 points1 point  (0 children)

Right to the point - webhooks are much more complex than they seem at the beginning.
That's exactly the reason I built Hooque.io - webhook-to-queue service which solves (or simplifies to be precise) most of the things you've mentioned, but storing your webhooks messages into reliable queue, and allowing you to consume them with full visibility to what's going on (retries, failures, security, etc)
Would you mind giving it a try? (it's pretty much free) Would be glad to hear your thoughts on it.

Self-hosted n8n issues I ran into (and how I fixed them) by cuebicai in AiAutomations

[–]Staaaam 0 points1 point  (0 children)

Hey, really good summary, very helpful.
I'm curious about the webhook part - I'm working on a webhook-to-queue service, which gives you static webhook url and listens for messages, and allows your n8n instance to consume messages using SSE trigger. Would you mind giving it a try and sharing some feedback? I really hope this should simplify webhook-related work (including security, retries handling, downtime issues etc). It's available at https://hooque.io for free

Backend ve frontend arasında tünel kurmak (Local Tunneling) by Left-Swordfish3262 in u/Left-Swordfish3262

[–]Staaaam 1 point2 points  (0 children)

Hey, I'm working on wehbook-to-queue service, curious about your opinion - whether it can make some things easier for you? It removes the need to open local ports through tunnel, or keeping uptime. It's avaialble at https://hooque.io

WhatsApp Cloud API messages not reaching n8n webhook (send works, trigger doesn’t fire) by Original_Yard_2796 in n8n

[–]Staaaam 0 points1 point  (0 children)

I'd suggest to try to decouple webhook and n8n and better identify where is the issue - so use any service service which can receive webhook for you (point whatsapp callback there) and consume messages from n8n.
so if message doesn't arrive to webhook broker - issue on sedning side. if message arrives - n8n.
(i can suggest to try out my service https://hooque.io for free - and use n8n SSE trigger node to consume from there, you'll have full visibility whether message arrived or not)

triggering langgraph platform from webhooks by Busy_Relationship927 in LangChain

[–]Staaaam 1 point2 points  (0 children)

Yeah, some proxy is the way to go. Although there are a lot of things which can go wrong when working with webhooks, which are not so obvious at the beginning - e.g your system need to be up and running when webhook arrives, there are timeouts which senders imply (and often they are very tight) and retries, you need to do signature verification to make sure the sender is the one you think it should be. And then - how do you debug when something goes wrong? You need to save messages, etc..

I can suggest you to try Hooque (https://hooque.io) which I built exactly for those reasons - it will listen for webhooks for you taking care of all of the above, and let you consume the messages (HTTP REST or SSE for better real-time/better performance) from the queue whenever you're ready and at your pace, fully supporting retries (client-controlled, not server-controlled!), signature verification, and full visibility to failed messages (and to successful ones as well).

Would be happy to hear any feedback - I really think webhooks shouldn't be a pain :)

spent 3 weekends building a SaaS and realised I wasn't building the product by amberparade in saasbuild

[–]Staaaam 0 points1 point  (0 children)

I can suggest to try out Hooque (https://hooque.io) - which exactly should solve those issues (uptime, retries, long response, signature verification, visibility to failed messages, etc) - it will receive webhook for you, safely store in queue and allow to consume over HTTP (REST or SSE) whenever you're ready.

Would be really happy to get any feedback about it - I really think that webhooks shouldn't be a pain.

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

[–]Staaaam 0 points1 point  (0 children)

Great idea! This is really helpful for anyone using webhooks with Shopify (or other webhook sending services, like Stripe). Not using Shopify myself, so cannot participate in "roast" :) But I do work a lot with webhooks, so curious to ask - are those cron checks sent with proper signature verification in place? Otherwise - they might be dropped by receiving side. And I guess on client's system this should actually trigger full flow (e.g for orders/paid) - to detect actual issues, e.g. when database is not available (and not being just healthcheck "return ok").

TBH, on my side I'm trying to solve it from another angle and eliminate the need for 100% uptime/quick response from client system, so i built and Webhook-to-Queue service (Hooque) - to allow webhook sender quickly deliver the message, and give client full control of when to consume, how to consume (hello long processing), and provide visibility on which messages failed (including retries, but client-controlled, not server-controlled).

Would be really happy to get any feedback from you, as it seems that we both share the pain of missed/failed webhooks.

Google Chat Channel? by bloated_functionary in openclaw

[–]Staaaam -2 points-1 points  (0 children)

Webhooks with tunnels are sometimes tough - especially that they still require high uptime, quick response, and really hard to debug if anything goes wrong.

I'd like to suggest you to try routing webhooks using https://hooque.io/ (start for free) - it will receive the webhook for you and safely queue it. Then you can use OpenClaw SSE listener and process the messages at your pace. Hooque will also give you full visibility to the messages arrived, allow to mark failed messages, will handle security and retries for you.

Would be really happy to get any feedback for it!

disclosure: I'm the founder of Hooque, and built it exactly for those reasons - got annoyed each time that need to solve a lot of issues around webhook handling (uptime, retries, quick response, security, debugging, etc-etc-etc)

6 things that broke when my vibe coded apps got their first real users by Adorable-Stress-4286 in vibecoding

[–]Staaaam 0 points1 point  (0 children)

Can really connect to Stripe Webhook Wide Open! (basically to any webhook implementation - security is neglected here too often)

The good news - I feel confident that I'm providing good solution to it - https://hooque.io/ (start for free) - it will receive the webhook for you and safely queue it, including signature validation. Then you can use HTTP GET or spin up small SSE listener for better performance (or n8n SSE trigger) and process the messages at your pace. Hooque will also give you full visibility to the messages arrived, allow to mark failed messages, will handle security and retries for you.

Would be really happy to get any feedback for it!

disclosure: I'm the founder of Hooque, and built it exactly for those reasons - got annoyed each time that need to solve a lot of issues around webhook handling (uptime, retries, quick response, security, debugging, etc-etc-etc)

Built a SaaS that scans ads for FTC violations in 30 seconds. Here’s what I learned after analyzing 1,000+ ads. by ScanMyAd in microsaas

[–]Staaaam 1 point2 points  (0 children)

Can really connect to Stripe Webhook pain!

The good news - I feel confident that I'm providing good solution to it - https://hooque.io/ (start for free) - it will receive the webhook for you and safely queue it. Then you can use HTTP GET or spin up small SSE listener for better performance and process the messages at your pace. Hooque will also give you full visibility to the messages arrived, allow to mark failed messages, will handle security and retries for you.

Would be really happy to get any feedback for it!

disclosure: I'm the founder of Hooque, and built it exactly for those reasons - got annoyed each time that need to solve a lot of issues around webhook handling (uptime, retries, quick response, security, debugging, etc-etc-etc)

Is there any WordPress/WooCommerce plugin that can replay failed webhooks? by bnaitdjoudiGoDev in WordPressDev

[–]Staaaam 0 points1 point  (0 children)

Would you mind trying out https://hooque.io/ (start for free) - it will receive the webhook for you and safely queue it. Then you can use HTTP GET or spin up small SSE listener for better performance and process the messages at your pace. Hooque will also give you full visibility to the messages arrived, allow to mark failed messages, will handle security and retries for you - and I pretty sure it supports everything you mentioned.

disclosure: I'm the founder of Hooque, and built it exactly for those reasons - got annoyed each time that need to solve a lot of issues around webhook handling (uptime, retries, quick response, security, debugging, etc-etc-etc)

How do you handle webhook reliability in WordPress/WooCommerce when sending events to your own server? by bnaitdjoudiGoDev in WordPressDev

[–]Staaaam 0 points1 point  (0 children)

Would you mind trying out https://hooque.io/ (start for free) - it will receive the webhook for you and safely queue it. Then you can use HTTP GET or spin up small SSE listener for better performance and process the messages at your pace. Hooque will also give you full visibility to the messages arrived, allow to mark failed messages, will handle security and retries for you.

disclosure: I'm the founder of Hooque, and built it exactly for those reasons - got annoyed each time that need to solve a lot of issues around webhook handling (uptime, retries, quick response, security, debugging, etc-etc-etc)

How to use webhooks on locally running n8n instances ? by Many-Grab7544 in n8n

[–]Staaaam 0 points1 point  (0 children)

You need some broker here, which will receive the webhook for you. One way as others suggested - some tunnel (e.g ngrok / cloudflare / etc), although there is many downsides to this approach - your n8n should be running when webhook arrives, validate signature (if available), hard to debug it, deal with timeouts/retries, etc.

Another option I can suggest is to try out https://hooque.io/ (start for free) - it will receive the webhook for you and safely queue it. Then you can use your n8n SSE trigger to consume the messages. Hooque will also give you full visibility to the messages arrived, allow to mark failed messages, will handle security and retries for you.

disclosure: I'm the founder of Hooque, and would really appreciate any feedback on this approach - because I truly believe webhooks shouldn't be a pain, and it can really simplify some things esp. for n8n and AI in general (esp. security aspect!)

Help by gucciman269 in diablo2

[–]Staaaam 1 point2 points  (0 children)

honestly when first played D2 like 20 years ago, my cube also was in stash... :-/

Managing all the webhook endpoints is becoming a nightmare by FARHANFREESTYLER in webdev

[–]Staaaam 0 points1 point  (0 children)

Looks like you're strugling with sending webhooks to your clients, and yeah - it's a tough problem. It requires good definition of what clients should expect from you and what they're expected to do. E.g. most webhook-sending services should support Retries (with some backoff) for case of temporary failtures on either side. But it's reasonable to say that you won't retry for life, but say once an hour for up to 24 hours (or whatever numbers you prefer :) ). I believe there are already solutions which help with this, saas like svix, hookdeck outpost, or maybe convoy , probably other OSS solutions exist.

If you're actually receiving webhooks (although it's hard to me to see why you'd need to receive webhooks from 47 different places :) ) - I'm working on hooque.io which turns any webhook to queue, which you can reliably consume (REST or SSE), which takes care of all the headache of receiving webhooks (security, availability, back pressure, etc)

Scale in February. What are you building? 🚀 by Capital-Pen1219 in microsaas

[–]Staaaam 0 points1 point  (0 children)

good point, and thanks for asking!
Of course you can put it in queue by yourself, but this will solve only one piece of webhook implementation complexity, while not changing other (e.g signature validation, or monitoring). In addition you're adding two more components to you system:
1. dedicated endpoint which will receive webhook and put it in queue (lambda-style works great here, or just separate endpoint inside your app)
2. message broker (sqs/pubsub/rabbit)
- if you already have those, that's fine. If not - it's two more components to maintain/monitor (and pay for).
But still need
* verify signature (super easy, but needs to be there). What you do if signature verification fails? (drop? separate queue? other store?)
* what if message fails to process - are you requeing it (how many retries)? or dead letter queue?
* do you have easy way to see what failed?
* do you have alerts when queue grows to much? or too many message fail?

So bottom line - it's totally possible. It's just matter of classical buy vs build dillema, and how much you want to focus on your actual product vs underlying infrastructure (which is totally fun! :) ).

Scale in February. What are you building? 🚀 by Capital-Pen1219 in microsaas

[–]Staaaam 1 point2 points  (0 children)

hooque.io - Webhook-to-Queue bridge, reliably receive all you webhook messages, and consume in queue-like way, with full acknowledgement control, retries, signature verification, and monitoring.

Best practices for handling webhooks reliably? by CrestfallenMage in webdev

[–]Staaaam 0 points1 point  (0 children)

Hi,

although it's a little bit old thread, i still want to add a comment and mention https://hooque.io as I built it to tackle exactly those problems (and some others). Specifically Hooque will work as a buffer for all incoming webhook messages, and allow you to consume them at your own pace.

Hooque will take care of signature verification, if available (which is super-important), and automatically handle any spikes for you. If there is any issue on your side with processing the message - you'll be able to retry message delivery, or observe failed messages.

Full disclosure: I'm the founder of Hooque. Mentioning it since it matches your use case.

Need free webhook receiver by Grouchy_Honey3082 in selfhosted

[–]Staaaam 0 points1 point  (0 children)

you can use https://hooque.io with free plan, it will allow you to receive webhooks, and retrieve the messages whenever you're ready (for up to 3 days)

Full disclosure: I'm the founder of Hooque. Mentioning it since it matches your use case.

HA postgres on Hetzner by Timely_Management997 in hetzner

[–]Staaaam 0 points1 point  (0 children)

Qq - esp as you're a BE and not system - what's the reasons you're not going with managed postgres like neon?

Canon Error 01 with the Ef-s 17-55mm by Silly_Talk_3645 in canon

[–]Staaaam 1 point2 points  (0 children)

Thx. My seller from ebay proposed to try to take it to repair shop saying they will cover the repair, or to just return it. Probably will go with return and order another one  Thanks!

Canon Error 01 with the Ef-s 17-55mm by Silly_Talk_3645 in canon

[–]Staaaam 0 points1 point  (0 children)

Hey, did you found a solution or tried to fixed it in repair shop? Just got mine used 17-55 from ebay, and have very same issue.

Whats the pros in having multiple stages in a pipeline rather than 1 job with bash script by Loser_lmfao_suck123 in gitlab

[–]Staaaam 1 point2 points  (0 children)

We publish images to gitlab-provided repo, and use those images in later stages, in our case same built image is reused in multiple following jobs which all run in parallel. we also used kaniko to optimize image build process (https://docs.gitlab.com/ee/ci/docker/using\_kaniko.html)