Verification Checklist

Use this checklist before considering the SMS notifications module complete. Every item should be a confident "yes" — not "I think so." If you are unsure about any item, revisit the relevant page before moving forward.

---

MSG91 Account

• I have created a MSG91 account at msg91.com using the project email address
• I have completed the KYC process and understand it takes 1–3 business days to approve
• I can log into the MSG91 dashboard and navigate the main sections
• I have located my Auth Key under Settings → API
• I have saved the Auth Key to VaultMate under the project name, category "API Key"
• I understand why credits never expire and have added an initial credit balance
• I know where to find the billing section and how to download GST invoices

---

DLT Registration — The Legal Requirement

• I understand that DLT registration is mandatory by Indian law since 2021
• I can explain in one sentence what happens without DLT registration: messages are silently blocked by carriers — no error, no delivery
• I know I only need to register on ONE DLT platform (Jio, Airtel, or BSNL) — not all three
• I understand the three things that require DLT approval: the business entity, the Sender ID, and each message template
• I know a Sender ID is 6 alphabetic characters representing the brand (e.g. EDTRCK)
• I understand that {#var#} is the placeholder syntax for variable parts of a DLT template
• I know that the message sent by my code must exactly match the approved template (same punctuation, same fixed words)
• I know the approval timelines: entity 2–5 days, Sender ID 24–48 hours, templates 24–48 hours
• I understand that starting DLT registration 1 week before launch is the minimum safe timeline

Explain this in your own words (write it out, do not just read it):

Why does my SMS get blocked without DLT registration, and what do I need to register?

---

Transactional vs Promotional SMS

• I can clearly state the difference:
  • Transactional = triggered by a user action, expected by the user, allowed 24/7
  • Promotional = marketing, unsolicited, restricted to 9 AM – 9 PM only
• I know that for a school management app, almost all SMS I send is Transactional
• I know that Promotional SMS requires a different DLT template category and user opt-in

---

Security — The Non-Negotiable Rules

• I understand that the MSG91 auth key must NEVER appear in frontend/React code — it belongs only in Supabase edge function secrets
• I can explain why: because any code that runs in the browser is visible to anyone using browser developer tools
• I understand that OTPs must NEVER be stored as plain text in the database — only as SHA-256 hashes
• I can explain why: if the database is compromised, a hash cannot be reversed to the original OTP
• I know OTPs must have an expiry time (5 minutes is standard) and a retry limit (3 attempts before invalidation)
• I know rate limiting is required on the send-OTP endpoint (max 3 sends per 10 minutes) to prevent SMS bombing

---

The OTP Flow — End to End

Without looking at the code, can you describe this flow? Write it out:

Expected answer:

1. User enters phone number
2. Frontend calls edge function send-otp
3. Edge function generates 6-digit OTP, hashes it, stores the hash in otp_verifications table with 5-minute expiry
4. Edge function calls MSG91 API with the plain OTP (MSG91 sends the SMS)
5. User receives SMS, types the OTP into the app
6. Frontend calls edge function verify-otp with the mobile number and the entered OTP
7. Edge function hashes the entered OTP and compares it to the stored hash
8. If match and not expired: marks as used, returns success
9. If no match: increments attempt count, returns error with attempts remaining

• I can describe this flow correctly from memory

---

Architecture Understanding

• I understand why SMS must always be sent from a Supabase edge function, never from the React frontend
• I know that every SMS send should be logged in a sms_logs table for audit and support purposes
• I understand idempotency — why checking "did I already send this SMS?" prevents duplicate messages from bugs or retries
• I know that a delivery status webhook from MSG91 can update the sms_logs table with confirmation that the message was actually delivered

---

WhatsApp vs SMS Understanding

• I can state at least 3 reasons why WhatsApp often outperforms SMS for Indian consumer apps
• I know WhatsApp API requires a Facebook Business Manager account (not just MSG91)
• I understand the 24-hour conversation window concept — outside of this window, only pre-approved templates can be sent
• I know the recommended production strategy: WhatsApp as primary, SMS as fallback
• I understand that WhatsApp API approval takes longer than SMS DLT registration — it is not a day-one setup

---

Practical Readiness

• I know where to find all MSG91 credentials in VaultMate
• I can set a Supabase edge function secret using the Supabase CLI
• I understand why MSG91_AUTH_KEY must be a Supabase secret, not an environment variable in the frontend .env
• I have reviewed at least one of the edge function code examples in this module and can explain what each section does

---

Before You Build in Production

Run through this final check before sending real SMS to real users:

• DLT entity, Sender ID, and all required templates are approved (not just submitted)
• MSG91 credits are loaded (minimum ₹500 recommended for early testing)
• All edge functions are deployed to Supabase
• All required secrets are set in Supabase (not just in local .env)
• Test mode verified first — sent at least one test OTP and confirmed it arrived
• Rate limiting is active on all send endpoints
• SMS logs table exists and is logging sends correctly

---

Completing This Module

If you have checked every box above with confidence, you are ready to implement SMS notifications in a production Indian app. Move on to the next module.

If any box gave you pause, revisit the specific page for that concept. It is far better to spend 20 minutes re-reading now than to discover a DLT issue or a security flaw after launch.