notification-services

Common notification-services that truly do not belong to a domain. These should be very rare.

Two directions of notification

The senders here split along who the message is for:

Notifications to the customer

The b2b customer (or their entities/users) is the audience — they're being told about their own account activity.

• renderEmailTemplate (@cfxlabsinc/notification-services/email-render) — pure React Email rendering from a stored { statusVariant, version, subject, body } row and flattened string variables. Async (Promise<{ subject, html, text }>) because React Email 2.x render is Promise-only; await it at the composition root. Import this subpath explicitly; nothing in this package bundles React Email. Delivery to the customer runs through the event-driven email-notification-handler lambda, which resolves recipients via CustomerNotificationService.getRecipients (customer-services) and renders with this renderer.
• EventPublisher / AdminEventPublisher (src/webhook/) — HMAC-signed domain events POSTed to the customer's webhook endpoint (the integrator consuming our API).

Notifications on behalf of the customer

The customer is the author, not the audience. The message is sent to a third-party recipient the customer is transacting with — someone who may have no CFX account at all — and is branded as the customer.

• CustomerSmsNotificationSender (src/sms/) — sends SMS such as the escrow "you've been sent money, tap to claim" text, branded with the customer's name (e.g. MoveMoney: JANE DOE sent you money). The recipient is the customer's payee, not the customer. Routes by destination number: US → Vibes, international → Twilio.

The Customer prefix is possessive — the customer's SMS — to keep this from being mistaken for an account-status channel. Do not wire customer-facing account notifications (status changes, receipts) through it; those belong in the "to the customer" senders above.