Definition
Multi-tenant means one platform serves many enterprises or brands. Each is a tenant, and data and permissions are fully isolated. SIMs, plans, users, orders, and agents in one tenant are not visible to another. White label is how the brand is shown. Multi-tenant is the data split and the usage charge that a SaaS model needs.
Core capabilities
- Data isolation: IoT SIMs, data plans, users, orders, agents, and distributors are separated by tenant id. Queries and writes carry that filter.
- Separate configuration: Each tenant sets its own operator connection, plan packaging, agent price list, and revenue-share ratio. One tenant’s settings do not change another’s.
- Usage billing: The platform can count SIMs, traffic, and orders per tenant, for SaaS usage charges or a resource quota.
How it pairs with white label
Multi-tenant answers data isolation. White label answers which brand is shown. They are often used together: the platform serves many enterprises as SaaS, each enterprise is a tenant, and that tenant has its own white label. A visitor sees that enterprise’s brand, and only that enterprise can see the data. The pattern fits an IoT SIM operations platform and a B2B2C provider.
How isolation is built
Isolation is usually a tenant id on the data layer. Every business table has the field, and every query and write filters on it. Creating a tenant assigns a namespace and its own operator connection, data plans, and agent price list. Usage and charges can be totaled per tenant for SaaS billing or a quota. The design has to hold up on performance, security, and growth, so one tenant cannot read another’s data.
What each tenant can run
A tenant can set its own operator mapping, plan packaging, agents, distributors, and user self-service. IoT SIMs, bills, and settlement statements stay invisible across tenants. Together with white label, a tenant can set its brand and domain so a visitor sees that brand. Multi-tenant is what lets the IoT Cloud Platform run as SaaS for many enterprises.
Tenant isolation
The split is a tenant id on each business table. Reads and writes both carry it. A new tenant gets its own namespace, its own operator connection, its own data plans, and its own agent price list. Usage and charges are totaled per tenant for usage billing or a quota. Performance, security, and room to grow all have to keep tenants fully apart.
How data is split when several tenants share one operator account
Multi-tenant means one connectivity platform serves many enterprises, and each has its own tenant id. SIMs, plans, orders, users, and channels carry the tenant when they are written. Queries and exports must carry the same condition. Filtering by enterprise name only on the page, while an API can pull the whole table with no tenant, means isolation was never established. Sometimes the operator account is signed by the platform and then divided internally among tenants. Sometimes the tenant brings its own account. The first case especially has to place the SIM into a tenant when the number range is stocked. It cannot wait until activation and then guess. The second case stores the operator certificate and the callback address by tenant. Tenant A’s suspend command cannot be sent with tenant B’s key. SimtoLink multi-tenant capability separates data and configuration quota. It does not replace the sign-in page with another color. A skin decides whose brand the user sees. The tenant id decides who the record belongs to.
What a tenant admin must not change at platform level
Inside a tenant, the selling price of a plan, the channel price list, the portal mark, and the tenant’s own users can be set locally. What only the platform level may change includes creating and disabling a tenant, the overall quota of an operator account, and moving a number range across tenants. If a tenant admin “transfers” a SIM to another enterprise name, and that name is only a customer inside this tenant, attribution can change. If it is another tenant, the change must be refused. When a tenant is disabled, stop new subscriptions and new activations first. How in-service SIMs are suspended or moved out needs a list. Marking the tenant deleted must not cascade-delete historical bills. Usage totals by tenant, used when the platform charges the tenant for connectivity management, follow SIM count, traffic, or order count as the contract says. They cannot be temporarily filled with another tenant’s usage. Job schedules, cache keys, and object-storage paths all include the tenant id, or an asynchronous export sends tenant A’s number file to tenant B’s download link.
What happens when the white-label domain and the tenant id are swapped
When a user visits a domain, the system should determine the tenant first, then load that brand and that set of SIMs. A domain pointed at the wrong tenant sends payment into the wrong merchant account, while the SIM is opened on another company’s number range. The check order is domain, tenant, payment merchant, and the default plans that can be sold. If any one is missing, do not go live. One tenant can have several domains. Several tenants cannot share one payment callback address that writes SIMs, unless the callback message carries a tenant mark that cannot be forged. Statistics reports between tenants are not visible to each other by default. If a platform operations account needs to troubleshoot across tenants, each query should record the tenant scope and the reason. Making “several departments” into several tenants means the departments cannot share the enterprise number range. When departments share a number range, attribution and permissions are enough. Do not create a tenant for each department. Sharing a number range between departments uses attribution and roles. A new tenant makes the number range impossible to share, and it also requires another payment merchant and another domain.