Reliable notification delivery, guaranteed by an outbox.
The word is never lost.
Hiram accepts a notification, writes it with its outbox row in a single transaction, and owns delivery from there: per-tenant providers, retries, idempotency and end-to-end tracing. If the database confirmed it, it will be delivered.
Email is live today. Push, SMS and WhatsApp are on the roadmap, behind the same API.
- Outbox pattern
- .NET 10
- PostgreSQL
- OpenTelemetry traced
- Multi-tenant by design
If the database confirmed it, it will be delivered.
Most notification stacks lose messages in the gap between your transaction and the send. Hiram closes that gap. The request and its outbox row commit together, so an accepted notification cannot quietly disappear.
- One transaction. The notification request and the outbox row commit together, or not at all.
- No silent loss. Once the commit succeeds, the relay picks the message up and drives it to delivery.
- Every attempt recorded. Each try writes a delivery attempt with its outcome, error and duration.
$ curl -X POST https://api.hiram.dev/v1/notifications \ -H "X-Api-Key: hk_live_7f3a…" \ -H "Idempotency-Key: evt-2207" \ -d '{"channel":"email","recipient":"ops@tenant.com", "subject":"Order confirmed","body":"…"}' HTTP/1.1 202 Accepted { "id": "ntf_01HZX…", "status": "accepted" }
Four steps from request to delivered
A single POST starts a path with a guarantee built into the second step.
Accept
POST to /v1/notifications with your API key. An Idempotency-Key makes the call safe to retry. You get 202 Accepted at once.
Persist
The request and its outbox row are written in one transaction. From this moment the notification cannot be lost.
Relay
OutboxRelay publishes the message and resolves the provider configured for the tenant, SMTP or Resend for email.
Deliver
A resilient send pipeline retries transient failures and records each attempt. Live tenants send for real, shadow tenants log without sending.
accepted→queued→sending→sent · with failed and suppressed as terminal outcomes
Honest about what is built
Email runs end to end in production. The rest of the platform is on a public roadmap, not in the marketing copy.
Live capabilities Available now
- Transactional emailTwo interchangeable providers per tenant: SMTP via MailKit, Resend over HTTP.
- IdempotencyA client
Idempotency-Keycollapses retries into one send for 24 hours. - Per-tenant API keys
hk_live_keys, stored only as a SHA-256 hash and revocable. - Live and shadow modesShadow tenants exercise the full path and log a would-send without delivering.
- Delivery auditCursor-paginated queries with every attempt, outcome and latency.
- End-to-end tracingOne OpenTelemetry trace spans accept, publish, consume and send.
- Multi-tenant isolationEvery domain table carries a tenant from the first migration.
Coming capabilities On the roadmap
- Push, SMS and WhatsAppMore channels behind the same request contract.
- TemplatesVersioned, per-tenant message templates with variables.
- Signed status webhooksDelivery callbacks verified with
X-Hiram-Signature. - Metering and creditsAn append-only credit ledger with per-tenant quotas.
- Configurable AI autonomyThree autonomy levels with a decision log and budget.
- Admin and dev portalTenant self-service, keys, dashboards and the Trestleboard changelog.
A plain REST API, documented like one
No SDK lock-in and no ceremony. JSON over HTTPS, predictable status codes and precise errors. Authenticate once at the Handshake, send, and read delivery back with cursor pagination.
Read delivery back
Query any notification and its attempts. Statuses map one to one to what the engine actually did.
| Notification | Channel | Status | Latency |
|---|---|---|---|
| ntf_01HZX4 | sent | 412 ms | |
| ntf_01HZX7 | queued | n/a | |
| ntf_01HZX9 | failed | 2.1 s |
Built on a sober stack
.NET 10 and ASP.NET Core at the edge, EF Core on PostgreSQL, RabbitMQ for the relay, Redis for fast paths and OpenTelemetry across all of it.
Run the whole thing locally with Docker and a single dotnet run per host. The API listens on port 3357.
Built in phases, in the open
Reliability first. Each phase ships a working slice before the next one opens.
Walking skeleton
Outbox, relay, consume and one trace from end to end.
Email in production
Real providers, idempotency, shadow mode, API keys and delivery audit.
Push, templates, webhooks
Channels beyond email, signed status webhooks and a dead-letter queue.
Metering and quotas
A credit ledger and per-tenant rate limits.
Intelligence
Configurable AI autonomy with a decision log and a budget.
Portal
Admin and dev portal, tenant self-service and the Trestleboard changelog.
Production hardening
k3s and KEDA, load tests and runbooks.
Questions, answered plainly
What is Hiram?
Hiram is a multi-tenant notification platform. You send a notification through one REST API and Hiram owns delivery: persistence, provider routing, retries and audit.
Which channels are available today?
Transactional email is live in production, through SMTP or Resend per tenant. Push, SMS and WhatsApp are on the roadmap, behind the same request contract.
How does Hiram guarantee delivery?
The notification request and its outbox row are written in a single PostgreSQL transaction. Once that commit succeeds the message cannot be lost, and a relay drives it to delivery with retries.
Is Hiram multi-tenant?
Yes. Every domain table carries a tenant from the first migration, and each tenant has isolated API keys, providers and delivery mode.
How do I authenticate and send?
Authenticate at the Handshake with a per-tenant API key, then POST to /v1/notifications. An Idempotency-Key makes the call safe to retry, and you can read delivery back with cursor pagination.
Is it production ready?
Email is production ready as of phase F1, with real providers, idempotency, shadow mode and full delivery audit. Later phases add channels, metering and a portal.
Start with the Handshake.
Spin up the dev stack, issue an API key and send your first notification in a few minutes. Everything runs locally on .NET 10 and Docker.
POST /v1/notifications · 202 Accepted · X-Hiram-Signature on webhooks (F2)