PRODUCT / INTERNAL BUILD · MESSAGING CPAAS

Multi-Tenant SMS & WhatsApp CPaaS Platform

A messaging infrastructure platform for businesses, SaaS companies, agencies and resellers to manage SMS/WhatsApp communication, campaigns, templates, tenants, routing, wallets and messaging APIs from one control plane.

SandeshX is a working multi-tenant messaging platform—tenant-aware control plane rather than a simple bulk-SMS dashboard. Not a Twilio seat you rent on this domain.

Multi-tenantCPaaSDLTWalletFastAPIKannel4:22

Canonical watch page for search and AI crawlers—the recording is the running product.

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 · FastAPI
  • PostgreSQL · Redis · Kannel · DLT

Video chapters

Jump points for humans and crawlers. Timestamps open the same recording on YouTube.

TimeSegment
0:00Platform, tenant & RBAC
One login that fans out to platform admin, tenant/reseller and RBAC users.
1:27Campaigns, DLT & wallet
Campaign create with approved templates, DLT sender IDs and prepaid wallet lock.
2:54Own the control plane
Owning a messaging control plane vs renting provider sub-accounts.
3:37Wrap-up
How the screens fit a real deployment and what to read next on this site.

Questions this demo answers

No. UnifiedPBX.in is a consulting and build practice. The recording is software you would operate or commission—not a public tenant login.

A 4:22 working-system walkthrough of SandeshX: platform/tenant/RBAC surfaces, campaigns with approved templates, India DLT sender IDs and prepaid wallet lock—real admin screens, not a marketing reel.

A messaging platform where many organizations (tenants/resellers) share infrastructure while keeping campaigns, contacts, wallets and delivery data isolated—with platform admin, RBAC and APIs.

Communications Platform as a Service for messaging: APIs, tenants, billing, campaigns, routing, analytics and integrations—not only a gateway that transports SMS.

A gateway primarily transports messages. A CPaaS adds the control plane: tenants, users, wallets, templates, campaigns, routes, reports and developer APIs. SandeshX demonstrates that control-plane side.

Yes—that is a primary use of this architecture: reseller hierarchy, prepaid wallets and campaign tooling on shared infrastructure you operate.

Yes. Platform operator plus tenant/reseller hierarchy (master/reseller/client via parent_tenant_id) with role-scoped desks.

Campaigns lock the wallet (SELECT FOR UPDATE), segment bill, then enqueue. Insufficient balance → no enqueue. Failed SMS is not auto-refunded on DLR in this build.

Yes—India-focused TRAI DLT: PE profiles, sender IDs and approved templates before broadcast when validation is enabled. DLT is not a global rule set.

Yes architecturally: REST/OpenAPI paths for campaigns, wallet, contacts and messaging from external apps; webhooks/delivery events for status. See the SandeshX case study for the API surface.

OTP/verification is a natural transactional use of the messaging APIs and routes. Campaign UI in the demo emphasizes template campaigns; OTP is a primary product use case for the same control plane.

Routes expose Kannel, Twilio and Gupshup. Campaign create currently selects by priority among active routes. LCR/weighted-split helpers exist but are unused; the worker does not auto-failover on DLR failure.

Yes—for SMPP-class SMS delivery. Kannel is not the WhatsApp engine; WhatsApp send in this build goes via Meta Graph (synchronous) where configured.

Yes as a channel on the same control plane (templates/sync). Do not confuse WhatsApp transport with Kannel/SMPP.

As a future layer: campaign assist, copy variants, segmentation, anomaly detection—with humans approving compliance-sensitive sends. Not claimed as shipped in this demo.

Related 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