{"id":3055,"date":"2026-09-30T16:25:24","date_gmt":"2026-09-30T10:55:24","guid":{"rendered":"https:\/\/www.smsgatewaycenter.com\/blog\/?p=3055"},"modified":"2026-09-30T16:26:11","modified_gmt":"2026-09-30T10:56:11","slug":"multi-brand-messaging-architecture-accounts-sub-users","status":"publish","type":"post","link":"https:\/\/www.smsgatewaycenter.com\/blog\/multi-brand-messaging-architecture-accounts-sub-users\/","title":{"rendered":"Multi-Brand Messaging Architecture: Accounts, Sub-Users and Reseller Child Accounts for SMS, WhatsApp, RCS and Telegram"},"content":{"rendered":"\n

Running several brands through one messaging platform is an account-boundary decision before it is a code decision. This guide maps what each brand owns on SMS, WhatsApp, RCS and Telegram, compares a single account, team sub-users, reseller child accounts and customer-owned accounts, and walks through the eight reseller user endpoints with the traps that break provisioning and credit transfers.<\/p>\n\n\n\n

\"Three<\/a>
Several brands, one platform: the account boundary decides what each brand shares and what it owns.<\/figcaption><\/figure>\n\n\n\n

Table of Contents<\/h2>\n\n\n\n
    \n
  1. The Short Answer<\/a><\/li>\n\n\n\n
  2. TL;DR<\/a><\/li>\n\n\n\n
  3. Four Tenancy Models, Not One<\/a><\/li>\n\n\n\n
  4. What a Brand Owns on Each Channel<\/a><\/li>\n\n\n\n
  5. Six Things the Account Boundary Decides<\/a><\/li>\n\n\n\n
  6. Decision Matrix: Where Each Brand Should Live<\/a><\/li>\n\n\n\n
  7. The Brand Registry Schema<\/a><\/li>\n\n\n\n
  8. Resolving Credentials Per Brand at Send Time<\/a><\/li>\n\n\n\n
  9. The Reseller User API at a Glance<\/a><\/li>\n\n\n\n
  10. Creating a Child Account and Reading It Back<\/a><\/li>\n\n\n\n
  11. The User Profile Row, Field by Field<\/a><\/li>\n\n\n\n
  12. Epoch Milliseconds and the Midnight IST Expiry<\/a><\/li>\n\n\n\n
  13. Moving Credits Without Double Spending<\/a><\/li>\n\n\n\n
  14. Reconciling Transfers with the User Credit History<\/a><\/li>\n\n\n\n
  15. Sender IDs, DLT Entities and Templates Per Brand<\/a><\/li>\n\n\n\n
  16. WhatsApp Numbers, RCS Brands and Telegram Bots<\/a><\/li>\n\n\n\n
  17. One Webhook Per Account: Routing Delivery Reports<\/a><\/li>\n\n\n\n
  18. Passwords and Credential Rotation for Child Accounts<\/a><\/li>\n\n\n\n
  19. Four Code Samples, Four Traps<\/a><\/li>\n\n\n\n
  20. Migration Checklist<\/a><\/li>\n\n\n\n
  21. Unspecified Behaviour and How to Code Around It<\/a><\/li>\n\n\n\n
  22. FAQs<\/a><\/li>\n<\/ol>\n\n\n\n

    The Short Answer<\/h2>\n\n\n\n

    When one system sends messages for several brands, the first decision is not the schema or the queue. It is where the account boundary<\/strong> goes, because on SMSGatewayCenter a few things exist exactly once per account: the SMS wallet, the SMS delivery report webhook and the Telegram bot. Everything that must be isolated per brand along one of those three axes (a separate budget, a separate delivery callback, a separate Telegram identity) needs its own account. Everything else (sender IDs, DLT templates, WhatsApp numbers, RCS brands and bots) can live side by side inside one account and be selected per request.<\/p>\n\n\n\n

    That gives four workable tenancy models:<\/p>\n\n\n\n

      \n
    1. One account, many brands.<\/strong> Cheapest to run. Brands are rows in your own registry, selected by sender ID, WhatsApp number or RCS bot on every call.<\/li>\n\n\n\n
    2. Team sub-users under one direct account.<\/strong> Separate logins for people, not separate tenants. Sub-users carry the main account’s products and payment type, cannot create further sub-users, and inherit pricing from the main account.<\/li>\n\n\n\n
    3. Reseller child accounts.<\/strong> Real, separate accounts created and funded through eight SMSApi\/reseller\/<\/code> endpoints. Each child has its own balance, its own RCS brand and bots, and its own login.<\/li>\n\n\n\n
    4. Customer-owned accounts connected through OAuth.<\/strong> For SaaS products where each customer should own the sending relationship.<\/li>\n<\/ol>\n\n\n\n

      For most engineering teams the right answer is model 1 for brands that share a legal entity and a budget, and model 3 for brands that need a hard budget wall, their own Telegram bot or their own delivery callback. The rest of this guide shows how to decide, how to model it, and how to drive the reseller API without double-crediting an account on a retry.<\/p>\n\n\n\n

      TL;DR<\/h2>\n\n\n\n