Skip to main content
Everything you send through OneXtel runs inside an account structure that controls who can send, on which channels, and against whose credit. Understanding it takes two minutes and saves a lot of confusion later.

The account model

TUC

A Tenant User Customer is the billable account. It holds the channel entitlements, the charging rules, and the credit balance. Most customers are one TUC.

Child TUC

A sub-account under a TUC, used to separate usage by department or by end client. An aggregator onboarding its own customers gives each one a child TUC.

User

A person who signs in. Every user belongs to a TUC, and a TUC can have many users.

Role

What a user is allowed to do. Roles are assigned per user and control access feature by feature.
Credits flow down this structure: OneXtel allocates credits to the tenant, the tenant distributes them to each TUC, and messages sent by any user draw down that TUC’s balance.
Whether you can create TUCs depends on your access level. A direct enterprise customer has a single TUC created during onboarding and manages users within it. An aggregator or partner with child-TUC licences manages both. See User management.

What to set up before you send

1

Add your users

Create a user for each person who needs access, and assign each one a role. See User management and Roles.
2

Generate an API key

Every API call and every plugin authenticates with an API key. Generate one under API → Generate an API in the portal — see API keys.
3

Register your callbacks

Delivery reports, inbound messages, and click events only reach your systems once a callback is registered against your API key. See Callback configuration.
4

Activate your channels

Each channel needs its own sender registered before you can send — a WhatsApp Business number, an RCS agent, or an SMS sender ID.
5

Get your templates approved

WhatsApp and RCS templates must be approved before a campaign can use them, and SMS templates must be DLT-registered where applicable.

Charging and billing

Charging is configured per TUC and applies to everything sent from it. Charge point. Each message category — OTP, transactional, promotional, government, SIM route, and a default — is charged either On Submission, the moment the message is accepted by the platform, or On Delivery, only once it actually reaches the recipient. On Delivery is the more favourable setting, since undelivered messages cost nothing. Billing type. Prepaid draws down a balance you top up in advance; Postpaid bills for usage after the fact. Validity. The number of days the charging configuration stays active.

Data masking

Two independent settings control what account users can see in reports: Both are set per TUC. Use them where staff need to monitor delivery performance without seeing customer data — a common requirement for outsourced support teams.

Platform features

Optional per-TUC settings — two-factor authentication, maker-checker approval workflow, time windows, template auto-match, and message expiry — are enabled at the account level. Contact your account manager to change them.