HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
svix
svix-webhooks
Rust2022–2023
svix / svix-webhooks

svix-webhooks

The open source and enterprise-ready webhooks service 🦀

4Distinct people
11Mentions
0Explicit recommenders
3.5KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

The open source and enterprise-ready webhooks service 🦀

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month11 dated mentions

Observed mentions: 2022-02-15 15:38:07 UTC to 2023-08-23 10:27:17 UTC.

012342022-02-01 00:00:00 UTC to 2022-03-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 commentsFeb 20222022-03-01 00:00:00 UTC to 2022-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-04-01 00:00:00 UTC to 2022-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-05-01 00:00:00 UTC to 2022-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-06-01 00:00:00 UTC to 2022-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-07-01 00:00:00 UTC to 2022-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-08-01 00:00:00 UTC to 2022-09-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-09-01 00:00:00 UTC to 2022-10-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-10-01 00:00:00 UTC to 2022-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-11-01 00:00:00 UTC to 2022-12-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsNov 20222022-12-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2023-01-01 00:00:00 UTC to 2023-02-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-02-01 00:00:00 UTC to 2023-03-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-03-01 00:00:00 UTC to 2023-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-04-01 00:00:00 UTC to 2023-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-05-01 00:00:00 UTC to 2023-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-06-01 00:00:00 UTC to 2023-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-07-01 00:00:00 UTC to 2023-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-08-01 00:00:00 UTC to 2023-09-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsAug 2023

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Feb 20222022-02-01 00:00:00 UTC2022-03-01 00:00:00 UTC413
Mar 20222022-03-01 00:00:00 UTC2022-04-01 00:00:00 UTC000
Apr 20222022-04-01 00:00:00 UTC2022-05-01 00:00:00 UTC000
May 20222022-05-01 00:00:00 UTC2022-06-01 00:00:00 UTC000
Jun 20222022-06-01 00:00:00 UTC2022-07-01 00:00:00 UTC000
Jul 20222022-07-01 00:00:00 UTC2022-08-01 00:00:00 UTC000
Aug 20222022-08-01 00:00:00 UTC2022-09-01 00:00:00 UTC101
Sep 20222022-09-01 00:00:00 UTC2022-10-01 00:00:00 UTC101
Oct 20222022-10-01 00:00:00 UTC2022-11-01 00:00:00 UTC000
Nov 20222022-11-01 00:00:00 UTC2022-12-01 00:00:00 UTC101
Dec 20222022-12-01 00:00:00 UTC2023-01-01 00:00:00 UTC312
Jan 20232023-01-01 00:00:00 UTC2023-02-01 00:00:00 UTC000
Feb 20232023-02-01 00:00:00 UTC2023-03-01 00:00:00 UTC000
Mar 20232023-03-01 00:00:00 UTC2023-04-01 00:00:00 UTC000
Apr 20232023-04-01 00:00:00 UTC2023-05-01 00:00:00 UTC000
May 20232023-05-01 00:00:00 UTC2023-06-01 00:00:00 UTC000
Jun 20232023-06-01 00:00:00 UTC2023-07-01 00:00:00 UTC000
Jul 20232023-07-01 00:00:00 UTC2023-08-01 00:00:00 UTC000
Aug 20232023-08-01 00:00:00 UTC2023-09-01 00:00:00 UTC101

What Hacker News says

11 sources
We opted for a more manual approach, we have a ctx!() macro[1] we use for wrapping errors we want to enrich that we then use like this[2]: ctx!(some_fallible_fund(foo))? I wodner if anyone is doing anything better? The nice thing about our approach is that we store the data on each error, so we get a full backtrace, even when using async. 1: https://github.com/svix/svix-webhooks/blob/main/server/svix-... 2: https://github.com/svix/svix-webhooks/blob/main/server/svix-...
In Enhance Rust errors with file and line details
Congratulations on the launch, it's something I've been meaning to build for a while, and was actually chatting with @onassar about it (also on this thread) when he built his. It's very much useful, don't let people discourage you just because it's not useful for them. :P Btw, if you are ever tired with managing your own webhook infra, we[1] do webhook sending as a service, and we have also open-sourced the core tech[2] in case you find it useful. [1] https://www.svix.com [2] https://github.com/svix/svix-webhooks
In Show HN: Jiter – Just in Time Webhooks
Amen. FWIW, we are open source, and we publish libraries that let anyone sign and verify webhooks, hoping to save people the work and have a unified standard. Libs: https://github.com/svix/svix-webhooks Docs: https://docs.svix.com/receiving/verifying-payloads/how-manua... The docs mention `Svix-Signature`, but we (and the libs) also support `Webhooks-Signature` which are useful for the generic standard. The fact that we don't have REST for webhooks is both silly and annoying. Especially since (as you can see on the list in the original post) many companies who implement webhooks end up doing it poorly.
In Collection of best practices for providing and consuming webhooks
Founder of Svix here. It's a great question, and there's no one definitive answer. Some context: I've been an open source developer for all my life, my previous business was also open source, and I spoke with a lot of people over the last year about the right license for us. The main choices are: copyleft like AGPL (you want AGPL, not GPL for server applications), permissive like MIT (which we chose[0]), or so called "fair-code" which are the not-quite-open-source variants like the SSPL. While AGPL and SSPL are "better for business", MIT is more aligned with our mission, and is better for fostering a community. You can read more about the thinking on our Show HN[1]. Either way though, all of what the stricter licenses do is make it harder for competitors to use your code in their own service. Which is important, but not the end of the wor
Read the rest
ld as competitors can always just copy your API, landing page, and everything else. [0] https://github.com/svix/svix-webhooks [1] https://news.ycombinator.com/item?id=30347858
In Launch HN: Convoy (YC W22) – Open-source cloud-native webhooks service
This is something I thought about a lot before switching to Rust at Svix[0]. What I came to realize though, that there are no "casts to any and move on", but rather there are silencing real bugs and praying you won't hit them. Almost every time I've ever tried to silence the type checker (in any other language) it resulted in a bug. Does it make you slower? Definitely at times, but it's mostly OK, and the code is pretty damn clean. You can check out our repo to see how it looks[1]. Edit: we don't use Actix, we use Axum, but the same holds for Actix too. [0] https://www.svix.com [1] https://github.com/svix/svix-webhooks
In Announcing Actix Web v4.0
tasn·Feb 15, 2022Submission

Show HN: Svix – Open-Source Webhooks Service Written in Rust

We are super excited to be open sourcing the Svix webhooks dispatcher! Svix makes it easy to send webhooks. You send your payload to Svix, and Svix takes care of deliverability, retries, security, and more. You can read more about why we built Svix in the original Show HN[0], though the gist is: our customers wanted webhooks to build integrations and workflows around our product, but we weren't willing to commit the engineering time, resources and ongoing maintenance required of a webhook delivery system. Why open source? On a personal level, I've been an open source maintainer and contributor for many years, and I care a lot about open source. So open-sourcing the Svix dispatcher was one of the first tickets I created on our issue tracker. As for the company, webhooks are currently a mess, everyone does them differently, with differing l
Read the rest
evels of quality and features supported. This is something we really want to fix. The Svix service is already making a difference there (we're lucky enough to call some really cool companies our customers), and open-sourcing the dispatcher is the next logical step to increase our impact. Why Rust? It's really fast, it makes writing secure and correct code easier, it's easier to deploy and distribute (one static binary), and it's a lot more fun. :) Webhooks are really cool, and I absolutely love what they enable. They make the web compose-able, interconnected, and enable people to automate a lot of their work! Our goal is to make them easy, reliable, and consistent, so that more services offer them and they are easier to consume. I'd love to hear your feedback! We've incorporated most of the comments we got the last time[0] (thanks again everyone!), and we would love to know how we can improve the product further. Got any suggestions? Homepage: https://www.svix.com Repo: https://github.com/svix/svix-webhooks/ Docs: https://docs.svix.com/ API reference: https://api.svix.com/ [0] https://news.ycombinator.com/item?id=26399672
176 points · Open discussion

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.