Stay found
In-app notifications
A durable inbox in your own database that your events write and your header badge reads — no vendor holding your customers' activity stream.
The problem
A notification count that's wrong is worse than none: the badge says three, you open the inbox, nothing's there, and you stop trusting it.
How it works
Notifications ship as a primitive: durable per-recipient rows in your own database, written when events happen — a new feedback ticket, a reporter's reply, an order confirmed. The badge reads them; the inbox page shows them; reads and dismissals are recorded so "unread" is a fact, not a dot that lies after a refresh.
Fan-out happens at write time, so "who should see this" is answered once, when the answer is known — not re-derived on every poll. Your events decide what rings it.
- Reads and dismissals recorded, so 'unread' stays a fact across refreshes
- Who-should-see-this is settled once, when the event happens — not re-guessed on every poll, so a later role change never rewrites who saw what last week
- Per-recipient rows in your own Postgres — still your customers' history the day a vendor's subscription would have lapsed
- Wired to events you already emit
npm install @adminigloo/notificationsBook a callAll features