- Type
- PRODUCT · INTERNAL BUILD
- Duration
- 4:22
- Stack
- Vue 3 · FastAPI · PostgreSQL · Redis · Kannel · DLT
- Proof
- YouTube · case study
Watch the demo
Open on YouTube → · Duration 4:22 · Full playlist
What this working demo shows
Direct answer: SandeshX as a messaging control plane—platform admin, tenant/reseller desks, RBAC, campaigns, India DLT templates/sender IDs, prepaid wallet lock and routes. The recording is the system—not a slide deck. Architecture & honest gaps: SandeshX CPaaS case study · Narrative: enterprise SMS article.
- Platform administration — operate the messaging infrastructure and tenants
- Tenant / reseller management — independent customer accounts on shared infra
- RBAC — platform vs tenant vs operational permissions
- SMS campaign management — approved templates + contact lists
- India DLT — registered sender IDs / templates before broadcast
- Wallet & prepaid billing — balance lock before enqueue
- Routes / gateways — Kannel, Twilio, Gupshup as provider options
- API-first integration — OpenAPI-documented REST for apps
What this is not
- Not a slide deck—the recording is the running product
- Not a hosted tenant you can subscribe to on this domain
- Not “rent a Twilio seat”—the pitch is owning the control plane
Client names stay off public pages where work is confidential. Figures on screen are from demo or evaluation data unless a linked case study says otherwise. Marketing tiles on the product landing (uptime/delivery claims) are UI copy—not used as results here.
Not just a bulk SMS panel
A traditional bulk-SMS tool uploads contacts and sends. SandeshX demonstrates a broader messaging control plane: tenants, users, campaigns, templates, sender identities, wallet billing, routing and APIs as one platform.
MESSAGING CONTROL PLANE
├── Tenants · RBAC · Wallets
├── Campaigns · Templates · DLT
└── APIs → Routing / Gateway
Kannel · Twilio · Gupshup
CPaaS vs gateway: a gateway transports messages; a CPaaS adds tenants, billing, campaigns, analytics and a developer platform. SandeshX demonstrates the control-plane side.
Multi-tenant & reseller architecture
YOUR CPaaS
├── Reseller A · Wallet · Users · Campaigns
├── Reseller B · …
└── Reseller C · …
→ Messaging gateway
Hierarchy: platform operator; tenant/reseller as master/reseller/client via parent_tenant_id. A tenant must never access another tenant’s campaigns, contacts, wallet or delivery data.
India DLT messaging architecture
India-focused TRAI DLT—not a global rule. PE profiles, sender IDs (header/route/status) and approved templates. When the DLT gate is on, mismatched traffic is never billed or queued.
Business → DLT registration → Sender ID → Approved template
→ Campaign / transaction → Gateway → Customer
Transactional vs promotional messaging
- Transactional — OTP, auth, alerts, order/payment updates, reminders
- Promotional — campaigns, offers, reactivation (consent rules differ by category/jurisdiction)
OTP & verification infrastructure
Login/registration/reset/2FA and transaction verification are primary use cases for the same API + route layer. Application → OTP API → SandeshX → route → gateway → delivery status → application.
Prepaid messaging wallet & billing
Demo shows prepaid wallet lock on campaign create. Pipeline: segment billing → SELECT wallet FOR UPDATE → insert messages → enqueue Redis sms:send. Insufficient balance → HTTP 400, no enqueue. Paytm/Razorpay credit the ledger via idempotent callbacks. Honest gap: failed SMS is not auto-refunded on DLR in this build.
Tenant → Wallet → Campaign → Balance check → Reserve/deduct
→ Send → Delivery report
Routes, gateways & honest routing status
UI exposes Kannel / Twilio / Gupshup. Worker uses provider + smpp_id from the selected route. Campaign create sorts by priority only. LCR and weighted-split helpers exist in code and are unused by create. Failover rows can be stored; the worker does not auto-fail over on DLR failure. Future path: weighted distribution, LCR, health-aware routing—labeled as evolution, not shipped behavior.
WhatsApp: control-plane channel with template sync; send via Meta Graph (synchronous) where configured—not via Kannel/SMPP. WhatsApp wallet cost is recorded as zero in this implementation.
Messaging APIs for business applications
CRM / ERP / E-commerce / SaaS / Mobile
→ SandeshX API (auth · tenant · RBAC)
→ Campaigns · Templates · Wallet
→ Messaging engine → Routes → SMS / WhatsApp
→ Delivery events → Reports / webhooks
OpenAPI-documented REST (case study counts OpenAPI paths from the running document). APIs first, screens second.
Scalable send path
API → Queue (Redis) → Workers → Gateway → Carrier
← DLR / event processor ←
Discuss with buyers: rate limits, provider limits, retries, idempotency, DLR processing, tenant quotas, observability. SMS send is async via Redis worker; WhatsApp create path is synchronous in this build.
Security & tenant isolation
- JWT auth, RBAC, tenant-scoped data
- API rate limiting and wallet transaction audit
- Template authorization / DLT gate before bill+queue
- Payment card data via Paytm/Razorpay—not stored on messaging servers (per UI copy)
AI-ready messaging — future extension
Not claimed as shipped. Possible: campaign assist, copy variants, segmentation, send-time hints, delivery anomaly flags, compliance assist—with human approval for compliance-sensitive sends. Connects to AI Automation / n8n: CRM event → workflow → SandeshX API → SMS/WhatsApp → webhook → CRM.
Multi-channel architecture
SandeshX control plane
├── SMS → gateway (Kannel / Twilio / …)
├── WhatsApp → Meta / BSP provider
└── Future: email · RCS · push (extensions)
Who this platform is for
- SMS / messaging providers building their own platform
- Digital agencies offering messaging to clients
- SaaS companies embedding SMS/WhatsApp
- Resellers needing tenancy + wallet billing
- Fintech / e-commerce needing OTP and transactional SMS
- Enterprise notification infrastructure (education, healthcare, ops)
- Teams that need APIs into CRM/ERP—not only a send UI
Technology in the recording / stack
SandeshX·CPaaS·Vue 3·FastAPIPostgreSQL·Redis·Kannel·DLT
Video chapters
Jump points for humans and crawlers. Timestamps open the same recording on YouTube.
| Time | Segment |
|---|---|
| 0:00 | Platform, tenant & RBAC One login that fans out to platform admin, tenant/reseller and RBAC users. |
| 1:27 | Campaigns, DLT & wallet Campaign create with approved templates, DLT sender IDs and prepaid wallet lock. |
| 2:54 | Own the control plane Owning a messaging control plane vs renting provider sub-accounts. |
| 3:37 | Wrap-up How the screens fit a real deployment and what to read next on this site. |
Questions this demo answers
Related demos
On this site
Demo → architecture → build.
SandeshX CPaaS case study → Enterprise SMS article → SaaS development → AI Automation → Full-Stack → All demos →Building messaging infrastructure or a reseller CPaaS?
Share tenancy, DLT needs, wallet model and whether OTP, WhatsApp or AI workflows come later. First reply is architecture—not a generic quote.
Discuss Your Project