Adal is public now. Looking for feedback from developers who work with webhooks
Adal is now public, and I'm looking for early feedback from developers who work with webhooks.
I'm Yuriy, the founder of Adal and a developer with 10+ years of commercial experience. Over the years, I kept running into the same problem: receiving real webhook requests from the internet on a developer machine is often more complicated than it should be.
Documentation does not always match the actual webhook payload. Test data is often too clean and repetitive. Real requests are usually much more useful for debugging because they reveal unexpected fields, headers, formats, and edge cases.
That is the problem Adal is trying to solve.
Adal gives developers permanent webhook endpoint URLs, stores incoming requests, shows delivery history, and lets requests be replayed or retried when needed. With the open-source Adal CLI, requests can also be delivered to a local machine when the developer connects.
A few days ago, I launched Adal on Product Hunt and got almost no feedback: a few upvotes, almost no comments, and no big launch moment.
At first, that felt strange. But it also made one thing very clear: launch is not distribution. Publishing a product is only the beginning. The harder part is finding the people who actually feel the problem.
So I'm posting this first update here.
If you build, test, debug, or operate webhook-based systems, I would really appreciate your feedback:
Is the positioning clear?
Does "permanent webhook endpoints + request visibility + replay" sound useful?
Where would you look for the first users of a developer tool like this?
Adal: https://adal.cloud
One thing I'd be careful with:
The interesting question may not be whether developers need better webhook visibility.
It's what they're actually trying to reduce by using it.
Those sound similar, but they can lead to very different positioning decisions.
That's a very useful distinction.
I think you are right: "better webhook visibility" is not the final outcome. It is more of a mechanism.
What developers and teams are probably trying to reduce is the time and uncertainty around webhook failures: figuring out whether the provider sent the request, whether the app received it, what was delivered, what failed, and whether the same case can be reproduced.
Adal approaches this by recording the full delivery path — from the incoming request to each delivery attempt and retry — but the outcome is not just "more logs". The outcome should be fewer black-box moments when something fails and nobody can clearly explain why.
Thanks for framing it this way. It gives me a better way to think about the positioning.
Possibly.
The reason I stopped short earlier is that I don't think the interesting part is the framing itself.
I think it's the decision that follows from it.
I wouldn't try to unpack that properly in a thread.
If you'd like the tighter version, drop your email and I'll put it together properly.
That makes sense, and I agree — the useful part is not just the framing, but what decisions it should lead to.
Indie Hackers does not allow me to post contact details yet, but my email is listed publicly on my Indie Hackers profile page.
I’d be glad to read your tighter version. Thanks for taking the time to think about this properly.
Sent you a note by email.
I think the decision matters more than the framing itself right now.