Laravel Notification Inbox Laravel Package

Product Decisions This Supports

• Build vs. buy for developer/QA tooling. This package is a low-cost substitute for custom "catch notifications in staging" plumbing: it captures non-mail notification channels and surfaces them in an in-app inbox so PMs, QA and support can see exactly what a user would have received — without a bespoke admin screen.
• Safe-by-default environment strategy. The v0.1.2 gate split (manageNotificationInbox, local-only by default) turns "who can read captured notifications" and "who can delete them" into two explicit product/permission decisions rather than one implicit one. This directly supports a defensible answer to "can a contractor with dashboard access wipe the QA inbox?"
• Data-handling and privacy posture. Configurable redaction now covers not just exact keys (redact) but any key containing password, passcode, secret, token, otp, code, private_key or webhook (redact_containing), plus an opt-in mask_codes_in_text (NOTIFICATION_INBOX_MASK_CODES) for 4–8 digit codes inside message bodies. This is a decision you can make per environment: dev can stay readable, shared staging should enable masking. Routes are deliberately never code-masked, so support flows remain debuggable.
• Scope of "interception." The corrected wording matters for roadmap honesty: only non-mail channels are caught instead of sent. Mail and database notifications still go out, and your own toX() methods still execute. So this package supports preview and inspection, not guaranteed suppression — plan a separate mailer/transport trap if suppressing email is a requirement.
• QA reliability for notification ordering/hooks. Registering the NotificationSending listener in register() (ahead of boot() listeners) means an app-level listener can no longer pre-empt interception. That reduces "it works locally but the inbox is empty after we added our own listener" flakiness in test environments.
• Operational ownership of inbox growth. Pruning is opportunistic (~1 in 50 captures) and now tunable via prune_lottery, with docs recommending a scheduled notification-inbox:prune. This is a small but real recurring-ops decision: who owns the schedule, and what retention window do we accept before the table bloats staging.
• Channel coverage roadmap input. Google Chat joining the channel table signals active maintenance across chat transports; useful when deciding whether this package covers your current channel mix (Slack/Teams/Discord/Chat) or whether a channel you rely on is still unrepresented.

When to Consider This Package

• Consider it when you want fast, cheap visibility into non-mail notifications (chat, SMS, push) during development, demos and QA, and you're comfortable with a pre-1.0, single-maintainer-style package in non-production environments.
• Consider it when your main pain is "nobody knows what the Slack/SMS message actually said" rather than "we need an auditable delivery log."
• Consider it when your team can absorb a small config surface (redact, redact_containing, mask_codes_in_text, manageNotificationInbox, prune_lottery) and will schedule the prune command.
• Look elsewhere when you need production-grade notification logging, delivery receipts, retries or an audit trail — this is a dev/staging inspection inbox, and mail and database channels bypass it entirely.
• Look elsewhere when guaranteed non-delivery is a hard requirement. The README's own correction says it: non-mail channels are "caught instead of sent," but mail and database are sent and your toX() code still runs. If a stray email or DB row in staging is unacceptable, add transport-level suppression.
• Watch the version. At v0.1.2 with an already-shipped behavioural change in listener registration ordering and a security-motivated permission split, treat minor bumps as potentially breaking: pin the version, read the changelog, and smoke-test the inbox after upgrades.
• Look elsewhere if you need per-tenant, end-user-facing notification history in the product itself — that's a product feature with its own data model and retention policy, not a debugging aid.

How to Pitch It (Stakeholders)

To executives: A small, configurable dev-tooling package that gives the team a window into the notifications our app would have sent on non-mail channels, so QA and support stop guessing and stop asking engineering to add throwaway debug code. The latest release hardens it: deleting or clearing the inbox now needs a separate permission (locked to local by default), sensitive fields are masked more aggressively before anything is written to disk, and one-off verification codes can be masked in message text with a single flag. Cost is near zero; the benefit is faster iteration on customer-facing messages and fewer "what did we actually send?" incidents in staging. It is explicitly not a production audit log, and it does not suppress email — those remain separate concerns.

To engineering: Adopt for non-production only, pinned to a version. Register the manageNotificationInbox gate wherever the inbox is reachable by more than one person; enable redact_containing everywhere and mask_codes_in_text in any shared environment. Schedule notification-inbox:prune and tune prune_lottery — pruning is opportunistic, not guaranteed. Note the interception listener now registers in register(), so it wins over app boot() listeners; that's the fix, not a bug, but re-verify after upgrades. Be precise about semantics with stakeholders: chat/SMS/push are intercepted, mail and database still send, and your toX() code still runs — if we ever need mail suppression, that's a separate transport trap.