Basic: Following are the rules describing relations in the accounts hierarchy:
Each flespi object (channel, device, subaccount etc.) has ONE owner defined by cid parameter (which corresponds to a particular customer_id).
Each account has ONE parent defined by owner_id parameter. Master account’s owner_id=0. Each account (except the fourth level accounts) can have multiple child accounts.
Parent account can MANAGE all its child accounts’ objects.
Child accounts objects can USE parent account objects.
Rule 1 establishes the position of each object relative to the subaccounts hierarchy.
Rule 2 defines the tree-like structure of subaccounts which in general case looks like:
Rules 3 and 4 define the rights of accounts going downward and upward through the hierarchy. Note that rules 3 and 4 use “parent-child” notation, which means that account can manage object from its “branch” of hierarchy “tree” only, and child object can use parent’s objects from it’s “chain” of parents up to the master account only.
Advanced: You can easily manage subaccounts via the API.
Parent accounts can emulate operation from any of its child accounts by setting a special x-flespi-cid HTTP header in each REST API call. Without such header, the request will operate with instances that belong to the branch of subaccounts for the account with the given authorization token. Consider the following account configuration: master account has two subaccounts, each having separate sets of devices:
If master needs to perform HTTP REST API call that operates with a set of devices that belong to Child 1 there are two ways to do so:
Perform a regular REST API call with Token DEF, that belongs to Child 1
Perform REST API call with master account Token ABC, adding the header: x-flespi-cid: XX, e.g.
curl -X GET --header 'x-flespi-cid: XX' --header 'Authorization: FlespiToken ABC’ 'https://flespi.io/gw/devices/all'
MQTT sessions created under the parent account token can subscribe to messages only generated on a specified flespi account’s namespace by passing the cid user property during subscribe request. If the cid user property was not specified by default, the session will receive all messages from its own account and all its child accounts. User properties can be used beginning from MQTT version 5.0. You can easily test this feature with MQTT Board.