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 an open source notification pipeline in development. It accepts signed events from the tools a team already uses, processes them outside the request, applies that team's rules, and delivers by email and WebSocket. Every delivery attempt is stored and searchable.
Early stage. The backend is implemented and runs locally. There is no hosted service 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.
From external event to delivered notification
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 the project stands
The backend is implemented and documented, and it runs on a developer machine with Docker. There is no hosted service and no commercial offering. The current backend should not be deployed for real users yet, because authorization on its management endpoints still needs work.
Directions under consideration, none implemented
- Simpler integration. Fewer steps from a new tenant to a first delivered notification.
- Delivery diagnostics. Clearer visibility into why a delivery failed or an event was not matched.
- Security and authorization. Authenticated management routes and token revocation.
- Deployment options. Exploring how and whether to host it.
Read the code, follow the build.