Business Features¶

The SMS Gateway is a multi-tenant A2P messaging platform for direct notifications and managed campaigns in Bangladesh. Its business capabilities span the complete message journey: authentication, tenant budgets, content validation, operator routing, charging, carrier submission, delivery tracking, refunds, reporting, and operational continuity.

This section describes what the platform offers and the rules users or operators can rely on. Implementation details are in System Architecture, while API request and response details are in the API Reference.

Capability map¶

Business domain	Primary users	Capabilities
Identity and access	Client applications, tenant users, platform operators	Login, JWT sessions, refresh rotation, logout, gateway authorization and administrative access separation
Client and balance management	Provisioning teams, finance operators, tenant administrators	Organization onboarding, prepaid/postpaid accounts, client users, top-ups and real-time balance checks
Direct messaging	Transactional systems and notification applications	OTP, transactional and promotional submission, multi-recipient sends, idempotent acceptance and status polling
SMS campaigns	Marketing and operations teams	Generic/personalized campaigns, inline or bulk CSV upload, preview, instant sending or scheduling, lifecycle controls, retry and resend
Routing, pricing and compliance	Messaging operations and commercial teams	Bangladesh operator detection, sender/CLI authorization, primary/secondary routes, carrier credentials, segment pricing and BTRC compliance, including the promotional sending window
Delivery, DLR and refunds	Client support, finance and messaging operations	Infozillion dispatch, delivery polling, terminal classification, direct/campaign refund ownership and safe reconciliation
Reporting and alerts	Reporting users, account managers and NOC teams	CDRs, campaign jobs, dashboards, billing summaries, CSV exports and channel-failure threshold alerts
Platform reliability and operations	SRE, NOC and platform operators	Service discovery, load-balanced ingress, transactional outboxes, bounded recovery, health diagnostics and horizontal scaling

How an SMS is processed¶

flowchart TB
    Submit[Client submits an SMS or campaign]
    Check[Check recipients, content, balance and BTRC rules]
    Prepare[Select route, calculate cost and charge balance]
    Queue[Accept and queue the messages]
    Send[Send messages to the mobile operator]
    Status[Check and record delivery status]
    Refund[Refund eligible failed messages]
    Report[Update reports and alerts]

    Submit --> Check --> Prepare --> Queue --> Send --> Status
    Status --> Refund
    Status --> Report

Hold "Ctrl" to enable pan & zoom

An accepted request has been checked, charged and queued. It does not mean the message has reached the recipient. Delivery happens afterward, and clients can follow the result through message status and reports.

External client features¶

Authenticate with username/password, rotate single-use refresh tokens, and explicitly revoke sessions.
Send 1–5,000 OTP, transactional, or promotional recipients in a direct request.
Create generic or personalized campaigns for up to 5,000 inline recipients, or upload promotional CSV files containing up to 1 million recipients for background processing.
Preview rendered segment counts and cost before creating an inline campaign.
Schedule, pause, resume, reschedule, cancel, and resend failed campaign recipients.
Poll aggregate message status or request recipient-level detail.
Use tenant-scoped idempotency keys to make submission retries predictable.

Operator and commercial features¶

Provision prepaid/postpaid organizations and client users.
Set a separate balance limit for each user or let users use the organization's shared balance.
Configure operator/IPTSP groups, credentials, channels, authorized sender CLIs, alternate routes and tenant-specific billing rates.
Inspect per-recipient CDRs, campaign job snapshots, daily dashboards and billing aggregates.
Export complete filtered report sets as spreadsheet-safe UTF-8 CSV.
Receive rolling channel-failure alerts through a webhook.

Key rules and limits¶

Area	What the platform does	What to know
Client access	Users can only view their own messages and campaigns	Internal service ports must remain private
Balance safety	Balance changes are protected against simultaneous spending	Do not retry a manual top-up or unkeyed debit when the result is unclear; check the balance first
Duplicate requests	The same idempotency key can safely retry the same message or campaign request for 24 hours	Do not reuse a key for different request details
Message queueing	Accepted messages are saved before they are queued for sending	Accepted does not mean sent or delivered
Campaign pricing	Content, message parts, rates and cost are saved when the campaign is accepted	Later rate changes only affect new campaigns; operators can still switch undispatched messages to a configured fallback route
Refund safety	Direct messages and campaigns have separate processes that prevent duplicate refunds	`NOT_AVAILABLE` and provider/local `9099` do not currently receive automatic refunds
Reporting	Repeated delivery events do not create duplicate report records	Reports and alerts can take time to update

Current limitations¶

The platform currently has these limits:

Operators select the secondary route manually; the platform does not automatically switch routes based on response codes or service health.
Response code 9099 is recorded as delivered and charged, even when caused by a timeout or circuit fallback.
After nine delivery-status checks without a final result, a recipient becomes NOT_AVAILABLE and is not automatically refunded.
Operators must manually review failed reporting events and exhausted queue/refund records; there is no self-service replay screen.
The same channel-alert settings apply to all clients and channels, and there is no alert-management API.