Tenancy Model

Sensos operates on a flexible, hierarchical tenancy model designed to accommodate both users and M2M applications. Understanding this structure is key to building and integrating applications effectively within the Sensos ecosystem. The model consists of tenants, accounts, resources, users, and M2M applications, each with specific relationships and access rules.

1. Tenant

The tenant is the highest organizational level in Sensos' hierarchy. It represents a business entity or organization. Each tenant manages a collection of accounts, resources, and users. Users and M2M applications are created at the tenant level, and their access to each account is granted there.

If a tenant is inactive, every API call for that tenant is rejected with 403 Forbidden and an empty response body.

2. Accounts

Each tenant can have one or more accounts. Accounts serve as containers for specific resources like devices, sets, and other assets. These accounts can be associated with one or multiple departments, teams, or any logical grouping within the tenant’s organization.

3. Resources

Resources such as devices, sets, and related entities are always associated with a specific account. There is no direct relationship between a resource and a tenant without going through an account. The resource structure is isolated to an account for better management and segregation.

4. Users

Users are assigned at the tenant level, and each user can be granted access to one or more accounts under the tenant. A user may not have access to any accounts, in which case they will not be able to interact with any of the tenant’s resources. Roles are assigned per account: a user can have a different role in each account, and the role determines what they can do with that account's resources.

A user can also be a tenant admin. Tenant admins have administrative rights across the whole tenant; for example, they can rotate the secret of any M2M application in the tenant, not only the applications they own (see Authentication).

5. M2M Applications

Machine-to-machine (M2M) applications are also created under a tenant. These applications are designed to interact with accounts and their resources programmatically. Similar to users, M2M applications can have access to one or more accounts within the tenant but may also have no access to accounts by default, depending on the configuration. An application's role is also assigned per account. A call to an account the application has no access to, or an operation its role does not allow, is rejected with 403 Forbidden and an empty response body.