Signed webhook ingestion
Senders sign the payload with HMAC-SHA256 and the platform checks it in constant time.
Anyone can POST to a URL. The signature is what lets a team trust that an event came from its own tooling.
Webhooks in, routed notifications out, with a record of every delivery.
DevNotify is being built so a team can point its CI, version control and monitoring tools at one endpoint, say who should hear about what, and see afterwards what was delivered. It handles signature checks, queuing, routing and delivery records, so each application does not rebuild them.
An early-stage product, built in the open. The backend is implemented and runs locally. A hosted version is the goal and does not exist yet.
- Event
- pushfrom github, signed with HMAC-SHA256
- Rule
- Notify on GitHub pushmatches event type push and source github
- Channel
- EMAILa rule can list EMAIL, WEBSOCKET or both
- Record
- One delivery rowPENDING, then SENT or FAILED, with a failure reason
Notifications are a backend job, not a feature toggle
Alerting on a build, a deploy or a pull request looks small. The work behind it is not: verifying who sent the event, keeping senders from waiting on email, deciding who hears about what, and knowing afterwards what was delivered.
DevNotify is built on the hypothesis that this work can live in one reusable pipeline instead of being rewritten per application. That is a design goal, not a proven market claim.
- Accept events safely
- Signed requests, checked before anything is stored.
- Never make the sender wait
- Events are queued, so delivery runs after the response.
- Route on conditions
- Per-team rules match on event type and source.
- Deliver on more than one channel
- Email and real-time WebSocket push today.
- Keep the record
- Notifications and delivery outcomes are stored and searchable.
One failed deploy, from event to delivery record
An illustrative scenario assembled from capabilities in the README. It is not connected to a running service and shows no real data.
Your CI sends an event
After a failed deployment, the pipeline posts a signed webhook to the team's ingest URL, labelled with an event type and a source.
POST /webhooks/acme/ingest X-Event-Type: deploy_failed X-Event-Source: jenkinsYou configured one rule
Created once through the API. Event type and source decide the match. Channels decide where it goes.
{"name": "Notify on deploy failure", "eventType": "deploy_failed", "source": "jenkins", "channels": ["EMAIL", "WEBSOCKET"]}DevNotify processes it
It checks the signature, stores the event, queues it and answers the sender. A consumer then matches the rule and creates the notification.
You can see the outcome
The email goes out and the WebSocket message reaches connected members. Each delivery is recorded as SENT or FAILED, and the notification can be found later by text search.
Try the rule matching
Three example rules, evaluated in your browser. A rule with no event type or source matches anything. Matching here is exact and case-sensitive, so check the source for production behaviour. Nothing is sent anywhere.
The architecture behind that sequence
Five stages, each a separate responsibility. The sender's request ends at the queue, and everything to the right of it runs asynchronously.
Verified before stored
Each webhook is signed with the tenant's API key. The secret never crosses the network, and a bad signature never reaches the queue.
Committed before queued
The event is saved to PostgreSQL first, then published to RabbitMQ, so a queued message always points at a real row.
One processing path
The queue consumer and the gRPC interface call the same rule-matching code, so results do not depend on how an event arrived.
What exists today
Five capabilities implemented in the backend and exercised through its local setup.
Asynchronous processing
Ingestion stores the event and hands it to RabbitMQ. Failed messages go to a dead letter queue instead of being lost.
A slow mail server cannot make a CI system's webhook time out.
Tenant-specific rules
Each team defines rules by event type, source and channel. Leaving type and source empty makes a catch-all.
What a team is notified about changes through the API, with no redeploy.
Email and WebSocket delivery
Email is sent asynchronously. WebSocket push reaches an individual member or a whole tenant topic.
Some alerts belong in an inbox and some in an open browser tab.
Delivery tracking and search
Every attempt is recorded as PENDING, SENT or FAILED, and notification history is indexed in Elasticsearch.
When something does not arrive, there is a record of what was tried and why it failed.
Who it is being built for
These are hypotheses about use cases. DevNotify has no customers or users to point to.
- Backend developers integrating webhooksPeople who receive events from GitHub, Jenkins or monitoring tools and want verification, routing and delivery handled in one place.
- Small teams building internal toolsTeams that need build, deploy and incident alerts without writing a notification backend of their own.
- Developers tired of repeating the same plumbingAnyone who has rebuilt signature checks, queue consumers and delivery logs for more than one application.
Built to be inspected
Spring Boot, PostgreSQL, RabbitMQ, Redis, Elasticsearch, gRPC.
The backend is a modular monolith with versioned SQL migrations, two deliberate caching strategies and a synchronous gRPC path beside the asynchronous one. The engineering page documents the API, versions, local setup and the known gaps.
Where DevNotify stands, and where it is going
DevNotify is an early-stage product. The backend is implemented and documented, and it runs on a developer machine with Docker. The goal is a hosted version that teams can use without running the infrastructure themselves. That version does not exist yet, and the current backend should not be deployed for real users until authorization on its management endpoints is addressed.
- BuiltSigned ingestion, queueing, per-tenant rules, email and WebSocket delivery, searchable history and a gRPC interface, in a local setup.
- NextAuthenticated management routes, simpler first-run setup and clearer delivery diagnostics.
- Later goalA hosted version, once the security work is done. Not started, and not promised on a date.
Who is building it
DevNotify is designed and built by Ashutosh Chaturvedi. The commit history and architecture notes are public, so progress can be checked rather than taken on trust. Portfolio and GitHub profile. Contact: contact@devnotify.tech.
Follow the build, or say what you would use it for.
There is no signup or waitlist. To say what you would use it for, ask a question or discuss the product, email the address above. Public feedback fits better as an issue on the repository.