WhatsApp support bot
Green API webhook support for customer commands, private chats, group chats, linked users, and safe customer replies.
Complete feature system
Every feature your SMM support bot system needs in one workspace.
The platform combines WhatsApp automation, Telegram automation, ticket support, provider routing, secure tenant settings, cooldowns, logs, broadcasts, subscriptions, and master admin controls.
System map
Customer command2274209 refill
Parsed
Admin APIOwnership verified
Safe
Provider routeexternal_id refill
Sent
SecurityEncrypted sensitive settings
Protected
Main bot features
Customer commands, ownership checks, and provider dispatch.
These features control the main customer-facing support automation flow.
Telegram support bot
Tenant-specific Telegram bot support with polling/webhook-ready flow, chat IDs, group routing, and linked Telegram users.
Bot ticket medium
Ticket subject rules can trigger order workflows from panel tickets while keeping SaaS support tickets separate.
Command parser
Handles speed, cancel, refill, balance, help/commands, bulk IDs, aliases, and strict silent behavior for unsupported messages.
Order ownership check
Fetches order details through Admin API and verifies that the order belongs to the linked customer username.
External ID dispatch
Provider groups receive clean external ID commands like external_id speed, external_id cancel, or external_id refill.
Automation logic
Rules that stop wrong requests before they reach providers.
The bot is not just forwarding messages. It checks order state, service rules, cooldowns, and route configuration first.
Provider route manager
Map provider domains, keys, and aliases to WhatsApp groups or Telegram groups with custom command templates.
Cooldown protection
Prevents repeated command requests for the same order and action within the configured cooldown window.
Dedupe protection
Avoids duplicate processing of repeated webhook or polling events using message/update keys.
Service rule engine
Supports service name parsing or cached service rules for start-time and refill eligibility decisions.
Refill rule logic
Checks completed status, refill coverage, lifetime refill, refill windows, and service metadata before dispatch.
Speed rule logic
Checks order status, remains, service start time, and cooldown before sending speed request to provider.
Workspace controls
Everything the customer/admin needs to manage the bot.
Each workspace includes setup, routing, communication, logs, templates, and support tools.
Linked customer chats
Link WhatsApp or Telegram chat IDs to panel usernames so the bot knows who is allowed to manage which orders.
Admin/privileged chats
Support/admin chats can be configured separately for controlled support-side operations.
Broadcast system
Send updates and announcements to linked users with delivery logs, retry safety, and plan-based medium control.
Response templates
Customize customer-facing messages for success, failed orders, provider missing, route missing, and API problems.
Logs and history
Command logs, message logs, dispatch logs, cooldown records, and ticket activity make debugging easier.
Runtime health
Workspace and master admin tools help monitor webhook, polling, cron, API, and configuration status.
Security and safety
Designed to keep sensitive data and customer actions controlled.
The system separates tenants, avoids exposing technical errors to customers, and protects sensitive configuration data.
Encrypted sensitive database data
Sensitive settings such as API keys, bot tokens, credentials, and connection secrets are designed to be stored securely instead of being exposed in plain frontend pages.
Tenant isolation
Each customer workspace has separate settings, routes, linked chats, commands, cooldowns, logs, subscriptions, and runtime state.
Safe customer replies
Technical provider/API errors are converted into customer-safe messages while detailed issues remain available in logs/admin areas.
Admin API based verification
The bot uses Admin API to fetch users, orders, services, ticket data, and verify ownership before any provider dispatch.
Cron locks
Cron runners use lock-style protection to avoid overlapping executions where supported by the hosting environment.
Plan restrictions
Allowed mediums and module access are controlled by subscription plan, so Telegram-only or WhatsApp-only plans stay restricted.
SaaS and business layer
Built for customers, subscriptions, plans, billing, and platform control.
The product is not limited to one bot. It is structured as a SaaS platform for multiple workspaces and support teams.
Billing and invoices
Customers can create invoices, choose plan/provider type, submit payment reference, and wait for approval.
Subscription control
Plan status, expiry, active modules, and allowed mediums are managed from the SaaS/customer workspace.
Master admin panel
Platform owner can manage customers, plans, invoices, subscriptions, support queue, templates, and runtime health.
Perfect Panel / Rental Panel support
The system supports panel adapter logic so workspace owners can select the backend panel type during setup.
Cron automation
Background runners handle Telegram polling, ticket support processing, broadcast dispatch, and service cache refresh.
Scalable SaaS model
The setup is designed for multiple customers, separate workspaces, individual billing, and controlled automation modules.
How the command flow works
From customer message to provider route.
Customer sends command
Example: 2274209 refill or multiple IDs separated by commas.
Bot verifies order
Admin API fetches order details and checks linked username ownership.
Rules are checked
Status, start time, refill coverage, cooldown, external ID, and provider route are checked.
Provider receives ID
The provider group receives clean text like external_id refill.
Logs are saved
Command result, provider dispatch, cooldown, and customer reply are saved.
Configuration modes
Use fast parsing or advanced cached service rules.
Service name parsing
The bot reads service wording such as Start : 0-1 Hour and Refill : 30 Days directly from service names.
- Fast setup
- Good for smaller catalogs
- No manual service cache required
- Depends on clean service naming
Cached service rules
Fetch services from panel API, cache service data, then define start-time and refill rules directly from the workspace.
- Better for larger panels
- More controlled refill logic
- Manual service-level decisions
- Cleaner long-term automation
Ready to launch
Turn support chaos into a controlled automation workspace.
Start with one channel, map your providers, link users, test the Admin API, and gradually enable advanced service rules and broadcasts.