Core Concepts – Account & Hierarchy Model

This page explains how accounts, hierarchy, and charging work in the SFT platform and how they affect API behaviour, object ownership, and billing flows.

Understanding this model is critical for correctly provisioning endpoints, assigning plans, and interpreting usage and charging data.

Account Types in SFT

SFT supports two types of accounts:

• Reseller

• Enterprise

Each account type has a specific role and set of responsibilities within the platform.

Reseller Account

A Reseller account represents an intermediary entity between BICS and Enterprise customers.

A Reseller:

• Can have child accounts that are either:

  • Other Resellers

  • Enterprise accounts

• Manages commercial configuration (plans, tariffs, addons) for its child accounts

• Cannot create endpoints

• Can assign SIMs to Enterprise accounts so they can be used

Reseller accounts typically act as commercial and operational parents, not as consumers of connectivity themselves.

Enterprise Account

An Enterprise account represents the final owner of the SIMs and endpoints.

An Enterprise:

• Is the final consumer of connectivity

• Can create and manage endpoints

• Assigns plans and addons to endpoints

• Generates usage, events, and traffic

All endpoint-level activity ultimately belongs to an Enterprise account.

Account Hierarchy Model

SFT uses a parent–child hierarchy model across accounts and endpoints.

The hierarchy can include multiple levels:

BICS
  └── Reseller
        └── (Reseller)
              └── Enterprise
                    └── Endpoint

Key rules:

• A Reseller can have Resellers or Enterprises as children

• An Enterprise is always a leaf account (cannot have child accounts)

• An Endpoint always belongs to an Enterprise

Ownership and Capabilities

Endpoint Ownership

• Endpoints are always owned by an Enterprise

• Only Enterprises can create, activate, suspend, or deactivate endpoints

• All endpoint usage, events, and counters are generated at the Enterprise level

SIM Assignment

• SIMs are typically owned or managed at a higher level

• Resellers assign SIMs to Enterprises

• Enterprises use assigned SIMs to create endpoints

Hierarchical Charging Model

SFT applies hierarchical charging whenever an endpoint generates traffic.

Charging occurs at each level of the hierarchy, using different commercial rules.

Charging Flow

When an endpoint generates traffic:

1. Endpoint → Enterprise

   • The endpoint is charged according to:

     • The Base Plan

     • Any Addon Plans assigned at the Enterprise level

2. Enterprise → Reseller

   • The Enterprise is charged for the same traffic by its parent Reseller

   • Pricing is based on:

     • Tariffs and addons the Reseller has assigned to the Enterprise

3. Reseller → BICS

   • The Reseller is charged by BICS

   • Pricing is based on:

     • Tariffs and commercial agreements between BICS and the Reseller

Each charging step is independent and may apply different tariffs, rate zones, or addons.

Parent–Child Charging Relationships

The charging relationship always follows a parent → child model:

At each level:

• The parent charges the child

• The same traffic volume is used

• Different commercial rules may apply

This enables flexible pricing models across the hierarchy.

API Scope and Account Context

API calls are always executed within the context of the account associated with the API credentials.

This has important implications:

• An Enterprise API user:

  • Can manage endpoints

  • Can retrieve endpoint usage and events

• A Reseller API user:

  • Cannot create endpoints

  • Can manage plans and assignments for child Enterprises

  • Can retrieve aggregated usage for Enterprises under its hierarchy

Calling an API from the wrong account context may result in:

• Empty responses

• Missing objects

• Authorization errors

Key Takeaways

• SFT supports Reseller and Enterprise accounts

• Only Enterprises can create and own endpoints

• Resellers manage commercial configuration and SIM assignment

• Charging is hierarchical, applied at every level

• The same traffic is charged multiple times using different rules

• Account context is critical for correct API behaviour