Absorbed from docs/roadmap/features/notification-channels/ so that directory can be deleted.
What exists today
Email and in-app notifications are live through Novu (lib/novu/) with 20+ workflows, and Resend delivers the email. As of #1524 every payload carries customer-ready values — recipient-zone dates, currency-formatted amounts, plan titles and labelled types. So the workflow layer, the payload discipline and the preference model are already built. This issue is about adding two transports, not about building notifications.
What is missing
SMS and WhatsApp as delivery channels, with per-channel user preferences.
The stated case is no-show reduction: SMS open rates are commonly benchmarked far higher than email — CPaaS vendors converge on a 95–98% range for SMS against 20–28% for email, though this is an industry estimate from delivery/response behaviour, not a pixel-measured or independently peer-reviewed study — and WhatsApp is the dominant messaging channel in India, which is the launch market. Reminders 24 hours and 1 hour before an appointment are the highest-value first workflows, since they map onto no-show behaviour directly. Whether a reply-to-reschedule affordance is worth the inbound-handling complexity is an open question and should not be assumed into scope.
What has to be settled first
Regulatory, and this is the blocking item. India requires DLT registration for transactional SMS under TRAI's Telecom Commercial Communications Customer Preference Regulations: the sending business, as the "Principal Entity," pre-registers its entity, Sender ID (header) and content templates on the DLT platform, and telecom operators enforce this at send time through real-time scrubbing — traffic that doesn't match a registered header + template pair is blocked outright, not delayed. WhatsApp Business Platform requires the equivalent up-front step for outbound content: message templates must be submitted to and approved by Meta before they can be sent, though that review is typically minutes to 24 hours — DLT registration (entity + header + template, first-time) is the slower critical path of the two and should be started first. #884 covers phone and SMS step-up verification and carries overlapping India DLT and DPDP analysis; read it first, and consider whether one DLT registration serves both.
Consent, and separately, DPDP. A phone number collected for account verification is not automatically consented for marketing or reminder traffic. The rule that is actually binding today is TRAI's TCCCPR consent regime, not DPDP: promotional communications require the recipient's opt-in, recorded as Digital Consent Acquisition against the DLT platform, independent of DPDP status, while transactional messages instead go through the DLT sender/template registration above. The Digital Personal Data Protection Act, 2023 and its Rules were in fact notified on 13 November 2025, but on a phased commencement — only the Data Protection Board's establishment and a handful of procedural provisions are in force today; the core notice-and-consent obligations on data fiduciaries (the part that would govern using a verification phone number for reminder/marketing traffic) do not commence until 13 May 2027. So DPDP is not yet a live blocking obligation for this feature; don't build to a DPDP consent deadline that hasn't started. The consent model still needs to distinguish transactional from promotional under TCCCPR now, and the existing consent timestamps on User are the place to start — but revisit before 13 May 2027, since the DPDP notice-and-consent duties will bind by then.
Cost per message, which unlike email is not negligible at volume and should be modelled against the no-show saving it is meant to buy. Model it against the current billing basis: WhatsApp Business Platform moved from conversation-based to per-message pricing on 1 July 2025 — each delivered Marketing, Utility or Authentication template is billed individually by category and destination country, non-template replies inside an open service window stay free, and Meta has further per-market rate changes scheduled for 1 October 2026. Do not cost this against the deprecated conversation-window model.
Related
#884 (phone/SMS step-up verification, India DLT and DPDP), #691 (notifications subsystem production-readiness audit), #399 (Novu webhook receiver for delivery tracking — a prerequisite if per-channel delivery is to be measured rather than assumed).
Source: docs/roadmap/features/notification-channels/README.md.
Claim validation (2026-09-07)
External/regulatory claims were checked against primary or near-primary sources; internal claims (package.json, schema, file paths, issue cross-references) were out of scope here and already verified by the orchestrator.
- India DLT registration mechanism — confirmed. The Principal Entity (the business) registers entity/header/template; operators enforce via real-time DLT scrubbing; unregistered or mismatched traffic is blocked, not delayed. Sources: TRAI TCCCPR, WebEngage DLT regulation guide.
- WhatsApp template approval — confirmed, and a lead-time nuance added: Meta's review is typically minutes to 24 hours, materially faster than first-time DLT registration. Source: Meta template categorization docs.
- WhatsApp pricing model — corrected/updated. The issue didn't previously state a pricing basis; added that Meta replaced conversation-based pricing with per-message pricing effective 1 July 2025, with further per-market changes scheduled 1 October 2026. Source: Meta pricing docs.
- DPDP Act/Rules enforcement status — corrected, escalation. The original text implied a live consent obligation under "Consent and DPDP." In fact the DPDP Rules were notified 13 November 2025 (Gazette 14 November) but commence in three phases (13 Nov 2025 procedural/Board provisions; 13 Nov 2026 Consent Manager registration; 13 May 2027 for the core notice-and-consent, breach-reporting and Data Principal-rights obligations). The consent obligation that is live today comes from TRAI's TCCCPR opt-in/DND regime, not DPDP. Sources: PIB notification, Shardul Amarchand Mangaldas phased-commencement summary. Orchestrator correction: the validation pass first recorded these dates as 14 Nov 2025 / 14 Nov 2026 / 14 May 2027. The Rules were notified on 13 November 2025 and gazetted on the 14th, so the phase boundaries fall on 13 Nov 2025 / 13 Nov 2026 / 13 May 2027. This repository's own
docs/compliance/08-dpdp-and-privacy.md already carries the correct phasing, web-verified 2026-06-05, and is the authoritative internal reference — read it before building anything DPDP-shaped rather than working from this issue. Flagging this prominently since an implementer following the original text could over- or under-build consent handling against the wrong regime.
- "SMS 98% open rate vs 20% email" — not a single traceable primary study; it's a convergent estimate across CPaaS/marketing vendors (Klaviyo, Attentive, Postscript, Validity-class benchmarks), based on delivery/response inference rather than pixel measurement. Text softened to say so plainly rather than presenting it as a hard figure.
- "WhatsApp 2B+ users" — the issue body doesn't state this number directly (only "dominant messaging channel in India," which holds), but the source doc's "2B+" figure is stale: Meta's last officially stated round number was 2 billion (2020); the current official figure, given on Meta's Q1 2025 earnings call, is 3 billion+ monthly active users. Noted here since it fed the source roadmap doc; no inline change needed as the issue text itself doesn't cite the number.
- Not independently re-verified: exact end-to-end DLT approval lead time in business days (sources gave inconsistent partial figures — 2-4 days for template scrubbing sync alone, full entity+header+template onboarding not clearly stated by any single source); the current India-specific SMS/WhatsApp vendor unit costs (MSG91/Twilio/Gupshup rate cards move independently of the regulatory questions this pass focused on).
Absorbed from
docs/roadmap/features/notification-channels/so that directory can be deleted.What exists today
Email and in-app notifications are live through Novu (
lib/novu/) with 20+ workflows, and Resend delivers the email. As of #1524 every payload carries customer-ready values — recipient-zone dates, currency-formatted amounts, plan titles and labelled types. So the workflow layer, the payload discipline and the preference model are already built. This issue is about adding two transports, not about building notifications.What is missing
SMS and WhatsApp as delivery channels, with per-channel user preferences.
The stated case is no-show reduction: SMS open rates are commonly benchmarked far higher than email — CPaaS vendors converge on a 95–98% range for SMS against 20–28% for email, though this is an industry estimate from delivery/response behaviour, not a pixel-measured or independently peer-reviewed study — and WhatsApp is the dominant messaging channel in India, which is the launch market. Reminders 24 hours and 1 hour before an appointment are the highest-value first workflows, since they map onto no-show behaviour directly. Whether a reply-to-reschedule affordance is worth the inbound-handling complexity is an open question and should not be assumed into scope.
What has to be settled first
Regulatory, and this is the blocking item. India requires DLT registration for transactional SMS under TRAI's Telecom Commercial Communications Customer Preference Regulations: the sending business, as the "Principal Entity," pre-registers its entity, Sender ID (header) and content templates on the DLT platform, and telecom operators enforce this at send time through real-time scrubbing — traffic that doesn't match a registered header + template pair is blocked outright, not delayed. WhatsApp Business Platform requires the equivalent up-front step for outbound content: message templates must be submitted to and approved by Meta before they can be sent, though that review is typically minutes to 24 hours — DLT registration (entity + header + template, first-time) is the slower critical path of the two and should be started first. #884 covers phone and SMS step-up verification and carries overlapping India DLT and DPDP analysis; read it first, and consider whether one DLT registration serves both.
Consent, and separately, DPDP. A phone number collected for account verification is not automatically consented for marketing or reminder traffic. The rule that is actually binding today is TRAI's TCCCPR consent regime, not DPDP: promotional communications require the recipient's opt-in, recorded as Digital Consent Acquisition against the DLT platform, independent of DPDP status, while transactional messages instead go through the DLT sender/template registration above. The Digital Personal Data Protection Act, 2023 and its Rules were in fact notified on 13 November 2025, but on a phased commencement — only the Data Protection Board's establishment and a handful of procedural provisions are in force today; the core notice-and-consent obligations on data fiduciaries (the part that would govern using a verification phone number for reminder/marketing traffic) do not commence until 13 May 2027. So DPDP is not yet a live blocking obligation for this feature; don't build to a DPDP consent deadline that hasn't started. The consent model still needs to distinguish transactional from promotional under TCCCPR now, and the existing consent timestamps on
Userare the place to start — but revisit before 13 May 2027, since the DPDP notice-and-consent duties will bind by then.Cost per message, which unlike email is not negligible at volume and should be modelled against the no-show saving it is meant to buy. Model it against the current billing basis: WhatsApp Business Platform moved from conversation-based to per-message pricing on 1 July 2025 — each delivered Marketing, Utility or Authentication template is billed individually by category and destination country, non-template replies inside an open service window stay free, and Meta has further per-market rate changes scheduled for 1 October 2026. Do not cost this against the deprecated conversation-window model.
Related
#884 (phone/SMS step-up verification, India DLT and DPDP), #691 (notifications subsystem production-readiness audit), #399 (Novu webhook receiver for delivery tracking — a prerequisite if per-channel delivery is to be measured rather than assumed).
Source:
docs/roadmap/features/notification-channels/README.md.Claim validation (2026-09-07)
External/regulatory claims were checked against primary or near-primary sources; internal claims (package.json, schema, file paths, issue cross-references) were out of scope here and already verified by the orchestrator.
docs/compliance/08-dpdp-and-privacy.mdalready carries the correct phasing, web-verified 2026-06-05, and is the authoritative internal reference — read it before building anything DPDP-shaped rather than working from this issue. Flagging this prominently since an implementer following the original text could over- or under-build consent handling against the wrong regime.