Which Webhook SaaS projects are clones and which ones are original?

[iyerusad]

https://www.google.com/search?q=hosted+webhooks+service
https://www.hookrelay.dev/blog/webhooks-as-a-service-comparison/

Too many of these hosted services appear to have nearly identical website, nearly identical APIs, nearly identical clones with some light code variable changing. One or two extensions in some cases seem built upon it.

• https://www.hostedhooks.com/
• https://getconvoy.io/
• https://www.hook0.com/
• https://www.svix.com/
• https://www.webhooks.io/
• https://hookdeck.com/
• https://webhookrelay.com/
• https://octohook.com/

Is someone cloning SVIX work? Other way around? I'm not too concerned about necessarily building ontop of existing work, but some of these seem like SaaS that doesn't have actual development ongoing and just got reskinned marketing pages ("Saas"-in-a-can). I'm happy to pay for hosted service (if only for the external relay aspect of it for a small biz), less excited for service that are docker container clones masquerading as actual service provider (when they close up shop in 6 months don't want to migrate URLs and more).

Any background/context around this?

[tasn]

Hey @iyerusad, thanks for reaching out.

Many of them are work-in-progress attempts at copying Svix that launched a few months after our initial success and copied much of our concepts, API, pricing (including the fine print), and even some of our poor naming choices. We have evolved quite a bit since, so not everything is the same anymore, but as you mentioned, you can definitely see the traces.

At the end of the day though, it's not really a comparison. Svix is robust, secure, and processes a large amount of webhooks every month for some of the world's best companies. The rest lack the webhooks expertise, get many things wrong (security and otherwise), and are not really innovating, just stuck copying us.

P.S, hookdeck, webhook relay and octohook deal with receiving webhooks (Svix does sending), so the above doesn't apply to them. Additionally, webhooks.io has been around for many many years, but has been defunct for a while, and also doesn't fall into the above category.

I hope this helps!

[iyerusad]

I tend to agree - the value is in the ongoing ownership: feature dev (as needed), bugfix, infrastructure resiliency improvements.

Couple questions around Svix if anyone knows:

• Any meaning to "Svix" - acronym, word, play on Short term Volatility IndeX?

• Infra: Roughly how does Svix endpoint resiliency look/feel like? I don't need hard specifics but Microsoft (and presumably part of Azure) floundered for a little bit yesterday, Cloudflare and AWS have had their fair share of "took down 30% of internet" outages. No snob either, I'm pretty sure Azure would of stayed up if they had failover to something like Digital Ocean/Linode in case of failure. If current game plan is "we only live on AWS" might be worth looking into.

• Infra: Does Svix do secondary endpoints? Browserless.io has neat thing where I can hit whole other continent load balancer endpoints, neatly improving chances should it be regional BGP mess up, DNS nonsense, or straight up Datacenter natural disasters. Sounds ridiculous, but a cheap buy for small business, since we've seen webhook regularly hit outages-type hiccups at even low volume (anything over 1k/day, 10k moreso, 100k/day is probably like roulette)

• Is there a use case for basic Relay (and retry and manual replay) webhooks at Svix? I've checked Common Usage Examples and it seems more geared toward scenarios of Apps, resellers, and large SaaS players; less so for small biz just trying to ensure their webhooks are fired, stored for a window of time, and retried to success, with nice to have manual replay. If you're familiar with webhooks.io, similar to that basic case.

• Is there an ELI5 on "Svix does sending [rather than receiving]"? If not already answered by above.

[tasn]

Hey, sorry for the delay, I missed the github notification.

I tend to agree - the value is in the ongoing ownership: feature dev (as needed), bugfix, infrastructure resiliency improvements.

Yup, exactly.

Couple questions around Svix if anyone knows:

• Any meaning to "Svix" - acronym, word, play on Short term Volatility IndeX?

The volatility index launched after us, so not that. :)

We wrote about the name here: https://www.svix.com/blog/diahook-is-now-svix/

• Infra: Roughly how does Svix endpoint resiliency look/feel like? I don't need hard specifics but Microsoft (and presumably part of Azure) floundered for a little bit yesterday, Cloudflare and AWS have had their fair share of "took down 30% of internet" outages. No snob either, I'm pretty sure Azure would of stayed up if they had failover to something like Digital Ocean/Linode in case of failure. If current game plan is "we only live on AWS" might be worth looking into.

We are not yet multi-cloud, but we are working towards that. Yeah, the centralization of cloud providers is a bit sucky, but on the other hand, if we are in the same (AWS) data center as our customers, we are down when they are.

• Infra: Does Svix do secondary endpoints? Browserless.io has neat thing where I can hit whole other continent load balancer endpoints, neatly improving chances should it be regional BGP mess up, DNS nonsense, or straight up Datacenter natural disasters. Sounds ridiculous, but a cheap buy for small business, since we've seen webhook regularly hit outages-type hiccups at even low volume (anything over 1k/day, 10k moreso, 100k/day is probably like roulette)

We had it for a while, and then we removed it for a variety of reasons (I guess we need a blog post), though we plan on doing it again in the next few months. The gist it: it oftentimes makes things worse, not better. Because a lot of the code assumes customer <-> svix calls are slow (high latency) and svix <-> database is fast. Though that's not the case if you distribute the edge servers without also moving the data store, which means that request latency was higher than it could/would be. We improved things in other ways to increase resiliency (e.g. our SDK does automatic retries, we have multiple regions, etc).

• Is there a use case for basic Relay (and retry and manual replay) webhooks at Svix? I've checked Common Usage Examples and it seems more geared toward scenarios of Apps, resellers, and large SaaS players; less so for small biz just trying to ensure their webhooks are fired, stored for a window of time, and retried to success, with nice to have manual replay. If you're familiar with webhooks.io, similar to that basic case.

Companies large or small may need replay/manual retry/etc when developing, and oftentimes in production too. It's the same thing, so there are benefits for everyone.

• Is there an ELI5 on "Svix does sending [rather than receiving]"? If not already answered by above.

Sending webhooks: Svix is an example of that. We help companies send webhooks (so build their webhook functionality and provide their customers with a great experience).
Receiving webhooks: Hookdeck is an example of that and it's essentially what you described. You receive webhooks and you want to add another layer to receive for you so that you can have visibility, retries, etc. when using webhooks by customers that don't already have it. If a company uses Svix, their customers don't need this.

[iyerusad]

No worries, just general questions. Sounds like a pretty mature product with experiences of trying some logical but turned out not perfect ideas.

What's SVIX performance look like? Public Dashboard? Initial google fu of svix performance returns unfortunately lot of stock market stuff.

[tasn]

I'm not sure I understand your questions, mind rephrasing?

[iyerusad]

I didn't know if SVIX had a performance dashboard of any kind. I found https://status.svix.com/ and that shows uptime, but I've seen those before with charts etc. I haven't used SVIX yet so I don't know yet what kind of metrics would make sense to chart (if any) but yea that was the spirit of the question. No worries if it isn't something customers would need in the SVIX model. Appreciate all the answers you provided thus far and looking forward to giving the product a go one of these days.

[tasn]

Yeah, we don't expose these metrics at the moment globally, though we expose information to customers directly (and working on exposing even more).