TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Launch HN: Convoy (YC W22) – Open-source cloud-native webhooks service

88 pointsby subomiabout 3 years ago
Hi HN, we’re Subomi and Emmanuel, founders of Convoy (<a href="https:&#x2F;&#x2F;getconvoy.io" rel="nofollow">https:&#x2F;&#x2F;getconvoy.io</a>). Convoy is an open-source webhooks service. We make it easy for developers to publish webhooks like Stripe and Twilio. Convoy is cloud-native so developers can deploy the container to wherever they host their applications.<p>Some time ago I built an API for local fintech companies alongside Emmanuel. While trying to sell this product, we were asked several times for webhooks. We didn&#x27;t find a great tool that was easy to use, language-agnostic and cloud-native; something that could scale independently of our core service. We decided to build it ourselves.<p>Webhooks are the glue of the modern internet. They are used for asynchronous communication by API providers to notify apps&#x2F;integrators about events that have occurred in their account. I like to say it as: if you make a payment on Shopify with Stripe’s checkout and Stripe fails to send a webhook event to Shopify’s servers about your payment, you won’t get a delivery of your package even though your card has been debited. This explains the importance of webhook events to many consumer apps.<p>Today, implementing a webhooks delivery system is a highly fragmented problem. Stripe&#x27;s system is designed for security (with features like replay attacks, rolling secrets etc), Twilio for performance (with features like connection override), Pagerduty for flexibility (with features like payload filtering) and many more. We&#x27;d love to make these features available to everyone with Convoy. We&#x27;re already helping a few companies solve problems they didn&#x27;t know they had because of the visibility Convoy gives.<p>API providers need to push webhook events reliably. It’s a pain to build this from scratch. At first glance, it seems like good old HTTP POST, but with time it becomes more tricky as the requirements pile up: dealing with bad endpoints, pushing events to multiple endpoints as configured by your user, rate-limiting of customer endpoints, security of delivery, UX for managing retries. We take care of all that and give you one less infrastructure to worry about.<p>Convoy is open-source software that exposes a REST API. Developers push events to it using the REST API (we aim to support other means of ingesting data in the future for high volume environments – this is a feature Shopify provides today) then we sign the payload, publish the events, apply retries, etc. We also provide a management UI to manually retry events to user endpoints.<p>Convoy consists of 3 core components—in addition to the REST API, there is a job queue and a storage layer. The REST API server is used to create applications, endpoints and events. The job queue currently supports 2 backends: in-memory and Redis. The storage layer currently supports 2 backends: on-disk and MongoDB. All events pushed to Convoy are saved to storage and enqueued on the job queue for workers to deliver.<p>Most of our users use our product to push webhook events to their customers’ endpoints. Customers also use Convoy as a broker for inter-service communication.<p>We make money by providing a managed service. We&#x27;ve been running the managed service for a while now and charge $1&#x2F;5k events, but those details are not on our website yet.<p>The repository is available at <a href="https:&#x2F;&#x2F;github.com&#x2F;frain-dev&#x2F;convoy" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;frain-dev&#x2F;convoy</a> and a getting started doc exists here: <a href="https:&#x2F;&#x2F;getconvoy.io&#x2F;docs&#x2F;guide" rel="nofollow">https:&#x2F;&#x2F;getconvoy.io&#x2F;docs&#x2F;guide</a>. Anyone can download the binary or Docker image from here: <a href="https:&#x2F;&#x2F;getconvoy.io&#x2F;download" rel="nofollow">https:&#x2F;&#x2F;getconvoy.io&#x2F;download</a> and run it wherever they choose - AWS, Azure, GCP, etc.<p>We’d love you to try it out and hear your thoughts! We’d also love to hear about your experiences building custom webhook software and the challenges you’ve faced?

12 comments

zokierabout 3 years ago
Very timely as I have just recently happened to be involved in building a webhook system. Some observations:<p>1) For something specifically advertised &quot;cloud-native&quot; I would have hoped to see direct integration to e.g. EventBridge&#x2F;SNS&#x2F;SQS (or their GCP&#x2F;Azure equivalents) instead of plain REST API.<p>2) It is bit weird that you need both Redis and MongoDB here. Is there particular reason why redis alone would not be sufficient?<p>3) I couldn&#x27;t at a glance find any docs on the API for receiving the webhooks beyond that small ruby example snippet.<p>4) You clearly are aware of the security things Stripe has done with their webhook implementation, so it is surprising that you have fair bit simpler model from the looks of it<p>Some specific security aspects that I noted:<p>a) Not having some sort of keyids or multiple signatures makes key rotation probably annoying<p>b) Keys are application-wide instead of per-endpoint<p>c) Only shared-secret available, no public&#x2F;private keypair option?<p>d) No timestamping for replay protection?<p>Not trying to be too negative about your solution, but its just that I have been thinking exactly these problems myself then they are kinda on top of my head.<p>There is a draft IETF specification for request signing, that seems relevant here. Maybe you could adopt it in Convoy too? <a href="https:&#x2F;&#x2F;datatracker.ietf.org&#x2F;doc&#x2F;draft-ietf-httpbis-message-signatures&#x2F;" rel="nofollow">https:&#x2F;&#x2F;datatracker.ietf.org&#x2F;doc&#x2F;draft-ietf-httpbis-message-...</a>
评论 #30470980 未加载
Syttenabout 3 years ago
Honest question, how is it possible to be viable as a business and offer your code as MPL (Convoy) or MIT (Svix)? I love open source but I would expect a stronger license like GPL to be used, why did we settle on very permissive license as the default? I get the brand is protected but is that really enough? I am legit curious to hear the founders&#x27; take on that.
评论 #30472346 未加载
评论 #30472145 未加载
评论 #30472258 未加载
toomuchtodoabout 3 years ago
Congrats on the launch, huge space with lots of product market fit to go around, value prop is very clear.<p>Do you have any plans to support PostgreSQL or an S3 compatible target as storage backends?
评论 #30469757 未加载
评论 #30470062 未加载
jedbergabout 3 years ago
How does your product differ from Svix(W21)? At first glance the two seem about the same.
评论 #30471691 未加载
abrahamabout 3 years ago
Password validation is broken. Tring to sign up using the password &quot;sweet85_been_tries_These&quot; shows a generic error message in the UI:<p>&gt; Http Failure Response For Https:&#x2F;&#x2F;Saas-Api.Getconvoy.Io&#x2F;Api&#x2F;V1&#x2F;Users: 400 OK<p>Looking at the HTTP response in DevTools shows the following error:<p>&gt; Validation failed: Password Password should be minimum of eight characters, including at least 1 alphabet and one number<p>The password should be valid according to the error message.
评论 #30471740 未加载
zomglingsabout 3 years ago
Nice, starred. We&#x27;ve been thinking about adding webhook functionality to our API but didn&#x27;t have time to work on it from scratch. Time permitting, we&#x27;ll give Convoy a shot. Thank you.
评论 #30470120 未加载
endlessvoid94about 3 years ago
How is this different from HoneyBadger&#x27;s HookRelay service? <a href="https:&#x2F;&#x2F;www.hookrelay.dev" rel="nofollow">https:&#x2F;&#x2F;www.hookrelay.dev</a>
评论 #30474076 未加载
shaeqahmedabout 3 years ago
&gt; Customers also use Convoy as a broker for inter-service communication.<p>Very cool product! But this part threw me off a bit, wouldn&#x27;t a distributed message broker like Kafka be a much better option for this use-case?
评论 #30476137 未加载
_whiteCaps_about 3 years ago
Nitpick, in your &#x27;Rate Limiting&#x27; section:<p>Avoid blasting too much events to a single endpoint at once with flexible rate limiting controls<p>I would write this as:<p>Avoid blasting too <i>many</i> events
评论 #30473070 未加载
ushakovabout 3 years ago
how does one receive YC-funding for open-source project?
评论 #30472189 未加载
评论 #30472754 未加载
WoahNounabout 3 years ago
I know it&#x27;s a different industry, but there is an existing start-up named Convoy. Has 500+ employees and $675M in funding.
francislavoieabout 3 years ago
Oh geez. As someone who lives in Canada&#x27;s capital, the word &quot;convoy&quot; is a bit of a trigger right now. Bah.
评论 #30474769 未加载
评论 #30475113 未加载