DLT · prepaid wallet · Kannel

Multi-Tenant SMS & WhatsApp CPaaS Platform

Kannel can bind SMPP. It cannot be the company. This platform puts PostgreSQL as the ledger, FastAPI as the decision layer, and a Redis worker as the send path — with three keys: platform, tenant/reseller, RBAC user.

For SMS operators, aggregators and reseller teams who need DLT, prepaid wallets and isolation — not one Twilio account for every agency.

Productized case-study delivery Scope-based estimator BYOC · Twilio · Telnyx · Sinch
Configure & request quote View case study Talk to architecture

Problems we solve

Teams that run this job on disconnected tools typically hit:

  • One aggregator login shared across agencies with no isolation
  • DLT templates and sender IDs live in a spreadsheet beside the composer
  • HTTP request waits on SMPP — you built a form, not a CPaaS
  • Concurrent campaigns overdraw the prepaid wallet
  • TRAI rejects traffic that was already billed
  • WhatsApp and SMS are two products with two logins
  • No platform overview of who sent what today
  • PAN posted to your API for “wallet top-up”

One platform: Approved template + contact list → DLT/consent gate → lock wallet → insert messages → Redis sms:send batches → worker → Kannel/Twilio/Gupshup → DLR

Platform, tenants & compliance

  • Platform admin vs tenant/reseller vs RBAC permission codes
  • Master / reseller / client tree via parent_tenant_id
  • DLT PE profiles and sender IDs (header, route type, status)
  • Approved-template campaign create — no separate Start button
  • Opt-out / consent skip before enqueue
  • OpenAPI 3.1 at /docs (65 paths in the documented build)

Wallet, send path & providers

  • Prepaid wallet with SELECT FOR UPDATE before enqueue
  • GSM/UCS-2 segmenter (160/153 and 70/67)
  • Async SMS worker with retries; WhatsApp sync in create (documented)
  • Kannel SMPP, Twilio and Gupshup adapters
  • Paytm checksum / Razorpay HMAC — PAN never on these servers
  • Idempotent payment callbacks; DLR status normalisation

Platform architecture

flowchart TB
  Vue[Vue 3 landing tenant platform]
  API[FastAPI OpenAPI]
  PG[(PostgreSQL ledger)]
  Redis[(Redis sms:send)]
  W[Worker retries]
  K[Kannel SMPP]
  HTTP[Twilio Gupshup]
  Vue --> API
  API --> PG
  API --> Redis
  Redis --> W
  W --> K
  W --> HTTP

Deployment: Cloud · VPS · On-premises · BYOC · Twilio · Telnyx · Sinch

Proven case study

This product is a productized delivery of the documented engineering case study — evidence stays on this page so you do not have to guess what was shipped.

  • 11 running screens on the case study (landing through Swagger)
  • 65 OpenAPI paths, 15 tags, 13 Alembic revisions counted from the spec
  • Platform overview, tenant dashboard, campaigns, DLT, wallet captured
  • Working-system video of the same product
  • Honest gaps labelled: unused LCR helpers, no Grafana, pause is weak
Platform Overview with SMS today tenants and routes
Platform admin — how many tenants, did anything go out today?
Campaigns Create and send with template list and DLT sender ID
Create is send — DLT gate before the queue.
Templates Compliance tab PE profiles and Sender IDs
TRAI before enqueue.
Wallet balance Add funds Paytm Razorpay
Lock the ledger, then enqueue. No PAN on this API.

Full case study with video and FAQ →

Configure this scope & send RFQ →

Built for

SMS operators

Own the control plane; SMSC is the adapter.

Resellers

Parent credited after client debit — margin rules scoped in discovery.

Indian enterprises

DLT PE, sender IDs and approved templates before broadcast.

CPaaS product teams

FastAPI + Vue + Redis worker — not a Twilio wrapper with no tenancy.

Integrated vs fragmented stack

Traditional setupThis product direction
HTTP waits on SMPPWallet lock + Redis batches + async worker
DLT in a spreadsheetPE / sender ID / template gate before billing
One Twilio account for all agenciesJWT tenant_id on mutating routes
Card data on your serversHosted Paytm/Razorpay checkout

Outcomes

No invented delivery-rate SLA. The running UI shows platform vs tenant vs permission codes, prepaid lock, DLT campaign create, and OpenAPI. Failed SMS is not auto-refunded on DLR in this build — documented residual.

Deployment & carriers

  • Managed VPS — operate on your cloud account with runbooks.
  • Your cloud — AWS/GCP/Azure; you own the account.
  • On-premises — regulated or air-gapped cores (quote adjusted).
  • BYOC / own SIP — your carrier contract or trunks on the PBX we deploy.
  • Twilio / Telnyx / Sinch — CPaaS pass-through shown in the estimator (planning only).

Estimates are scope-based planning figures — not binding quotes. Taxes, carrier deposits, DIDs and third-party AI usage are scoped in discovery.

Frequently asked questions

Is this Twilio?

It is a multi-tenant messaging control plane you operate, with Kannel/Twilio/Gupshup as adapters.

Does it include voice/PBX?

No. Voice is FreeSWITCH CCaaS or UnifiedPBX — different products.

TRAI / DLT?

PE profiles, sender IDs and approved templates; toggleable DLT_VALIDATION_ENABLED.

Can resellers sit above clients?

Yes — parent_tenant_id tree. Margin rules should be confirmed in discovery.

WhatsApp?

Optional Cloud API sync; send path in this build is synchronous inside campaign create.

Will concurrent campaigns overdraw?

Wallet row lock + segmenter; insufficient balance → HTTP 400, no enqueue.

Can we use our SMSC?

Kannel SMPP or HTTP providers — selected as routes.

Deploy?

API/UI local or VPS; Compose for Postgres/Redis; Kannel optional profile. Kubernetes not claimed.

Requirements

Request formal quote