Very timely as I have just recently happened to be involved in building a webhook system. Some observations:

1) For something specifically advertised "cloud-native" I would have hoped to see direct integration to e.g. EventBridge/SNS/SQS (or their GCP/Azure equivalents) instead of plain REST API.

2) It is bit weird that you need both Redis and MongoDB here. Is there particular reason why redis alone would not be sufficient?

3) I couldn't at a glance find any docs on the API for receiving the webhooks beyond that small ruby example snippet.

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

Some specific security aspects that I noted:

a) Not having some sort of keyids or multiple signatures makes key rotation probably annoying

b) Keys are application-wide instead of per-endpoint

c) Only shared-secret available, no public/private keypair option?

d) No timestamping for replay protection?

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.

There is a draft IETF specification for request signing, that seems relevant here. Maybe you could adopt it in Convoy too? https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-...

Thanks for this well detailed feedback.

1) Yes, it's on our roadmap.

2) It was/is a design choice, we aren't so familiar with using redis as a persistence store. The goal was to enabled people switch backends depending on what they're comfortable with.

3) Thanks for bringing this up, there are a ton of things we should document.

4) We're working on improving things from a security perspective.

On application-wide keys, we're considering making this configurable, so you can choose what works best for you, we only started with app-wide keys, next is endpoint-keys. :)

On public/private keypair, this is new to me as well! we haven't found anyone doing this in prod. But yes, I can see how this can be useful in specific environments, definitely something we'd like to support.

We’re not currently providing we hooks, but I can see a using something like this if we need to at some point.

I’d definitely appreciate a Postgres options for the queue backend. We currently have an “everything in Postgres” approach for operational simplicity. It works great, and it would fantastic if we could slot this in there too.

Hmm. To clarify, do you mean Postgres as a queueing backend or storage backend?

We have it planned for a storage backend but not for queueing at the moment.