FUNCTIONS / @SPFN/NOTIFICATION — EMAIL, SMS & SLACK

One send(),
every channel.

Email, SMS, Slack — @spfn/notification gives each channel the same call shape: recipient, template, data in; a SendResult back, never a throw. Providers plug in, templates render with filters, and pg-boss carries the scheduled and the bulk.

Read the reference Get started $ pnpm add @spfn/notification
01
The premise

Not three integrations.
One delivery surface.

Notifications are the same job in every app: render a message, hand it to a vendor, remember what happened. This package ships that job as one surface — a template system with variable substitution and filters, delivery through pluggable providers, scheduling and distributed bulk sending on pg-boss, and an optional history table with engagement tracking on top. It configures from environment variables by default, with configureNotification for code-level overrides, and every send resolves to a SendResult you check instead of an exception you catch.

sendEmail / sendSMS / sendSlack
template + filters
provider
SendResult
FIG 01 — ONE PIPELINE PER CHANNEL · RESULTS, NOT EXCEPTIONS
02
Core technique

The vendor is
a plug-in.

A provider is a name and a send() function — nothing more. AWS SES and SNS come built in, but as optional dependencies: their SDKs install only if you use them. Adding SendGrid or Twilio means implementing that one function and calling registerEmailProvider or registerSMSProvider; picking a vendor is a config value (provider: 'aws-ses') or an environment variable. Your application code — sendEmail, template, data — never mentions the vendor, so swapping the delivery service is a registration and a config line, not a rewrite.

your code: sendEmail()
provider registry
{ name, send() }
FIG 02 — PROVIDER = NAME + SEND() · AWS SDKS OPTIONAL · SWITCHED BY ONE CONFIG VALUE
03
What's inside

The parts you'd otherwise
build again.

Plug it in.