Lumarin.Notify.EntityFrameworkCore.PostgreSQL 0.8.0-preview.199

Lumarin.Notify

Lumarin.Notify is a .NET notification library for applications that need a consistent send API, durable delivery options, current-actor receiver APIs, and optional operator-facing capabilities.

Use it when you want to keep notification delivery inside your application boundary while still supporting features such as templates, delivery tracking, preferences, devices, SignalR refresh hints, outbox delivery, and admin APIs.

When to use it

• You want one notification model across in-app feed, email, push, SMS, or webhook delivery.
• You need an adoption path that can start simple and grow into durable or outbox-backed delivery.
• You want hosted receiver APIs under /api/notify/* or a host-owned facade over the same services.
• You need clear boundaries between library-owned behavior and host-owned auth, tenant semantics, and deployment choices.

Key capabilities

• Unified INotificationHub send API.
• Simple, durable, and explicit outbox composition modes.
• Current-actor receiver APIs for feed, preferences, devices, templates, and tracking.
• Optional generated client for the stable hosted contract.
• Optional SignalR realtime fan-out as a refresh hint beside persisted feed state.
• Optional admin APIs, policy routing, scheduling preview, and telemetry helpers.
• Optional embeddable Admin UI and Receiver UI package surfaces.

Quick start

Start with the smallest supported profile and add capability layers as needed.

builder.Services.AddLumarinNotify(options =>
{
    options.Delivery.EnableBackgroundWorkers = false;
    options.EnableTemplates();
});

Add durable storage when you need persisted notifications and background delivery:

builder.Services.AddLumarinNotify(options =>
{
    options.UsePostgreSql(builder.Configuration.GetConnectionString("LumarinNotify")!);
    options.EnableHostedApiDefaults(hosted => hosted.ScopeType = "user");
});

Send a notification:

var result = await hub.SendAsync(new NotificationRequest(
    ScopeType: "user",
    ScopeId: "user-123",
    Category: "order.shipped",
    Content: new NotificationContent("Order shipped", "Your order #456 is on the way."),
    Recipients: new NotificationRecipients(
        Identities: ["user-123"],
        Channels: [NotificationChannel.InApp, NotificationChannel.Email])));

Supported integration shapes

Package map and docs

• Start here: docs-site/docs/getting-started.md
• Choose a starting path: docs-site/docs/get-started/choose-your-path.md
• Package selection: docs-site/docs/package-map.md
• Support posture: docs-site/docs/support-matrix.md
• Stability vocabulary: docs-site/docs/stability-tiers.md
• RC public API posture: docs/reference/public-api-stability.md
• RC package surface audit: docs/reference/package-surface-audit.md
• Shipping and upgrade review: docs-site/docs/adoption-checklist.md
• Hosted routes and identity model: docs-site/docs/aspnetcore-hosting.md
• Receiver integration choices: docs-site/docs/receiver-integration.md
• Receiver UI package guide: docs-site/docs/receiver-ui.md
• Admin control-plane guide: docs-site/docs/admin-control-plane.md
• Integration patterns: docs-site/docs/integration-patterns.md
• Scale and performance: docs-site/docs/scale-and-performance.md
• Extensibility seams: docs-site/docs/extensibility.md
• Hosts and samples: docs/reference/hosts-and-samples.md
• Upgrade notes: docs/release/upgrade-guidance.md
• Contributor workflows: docs/contributing/workflow.md

Stability and release status

The current package set is published as 0.8.0-preview.1.

The packageable UI libraries remain supported-optional release-candidate surfaces with their own npm metadata and package checks. Keep their published posture aligned with the same control-plane versus user-plane boundaries as the .NET packages.

Lumarin.Notify uses these repo-wide tiers:

• Stable: core runtime, durable EF packages, production channel families, the library-owned /api/notify/* contract, and the generated hosted client
• Supported optional: outbox, admin, policy routing, telemetry helpers, claims helpers, and bridge packages when adopted intentionally
• Preview: scheduling, webhook delivery, and preview provider adapters such as Postmark, Mailgun, Resend, APNs, Azure Communication Services SMS, Amazon SNS push or SMS, Telnyx, and Vonage
• Sample-only: reference host, runnable samples, and showcase tooling
• Internal: repo-local generators and helper settings

Use docs/release/checklist.md and docs-site/docs/release-candidate-readiness.md when you need the release-quality validation posture.

Boundaries and non-goals

Lumarin.Notify does not provide:

• IdP-specific authentication integration
• a tenant-management API
• a dashboard product or mandatory telemetry backend
• a general-purpose workflow or scheduler platform
• product-owned /api/me/* routes when your host needs a custom receiver contract

The host remains responsible for authentication, authorization, tenant resolution, deployment topology, migrations ownership, and provider credential management.

Validation commands

Run the narrowest command that matches your change. Common validation lanes are:

dotnet build Lumarin.Notify.slnx
dotnet test Lumarin.Notify.slnx -m:1
./scripts/verify.ps1 -Fast
./scripts/verify.ps1
./scripts/verify.ps1 -Full
./scripts/verify-docs-alignment.ps1
./scripts/verify-generated-openapi-clients.ps1
npm run build --prefix docs-site

For the packageable UI surfaces, also run the matching package checks:

Push-Location admin-ui
npm run typecheck
npm run typecheck:lib
npm run test:run
npm run build
npm run build:lib
npm run check:publint
npm run check:types-wrong
Pop-Location

Push-Location receiver-ui
npm run typecheck
npm run typecheck:lib
npm run test:run
npm run build
npm run build:lib
npm run check:publint
npm run check:types-wrong
Pop-Location

Use ./scripts/verify.ps1 -Full for the local lane that most closely mirrors the union of the main CI verification jobs. For release work, also use docs/release/checklist.md.