This article covers how to manage flespi objects with relation to different subaccounts on the example of GET /devices request.

HTTP 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:

1. Perform a regular REST API call with Token DEF, that belongs to Child 1

2. Perform REST API call with master account Token ABC, adding the header: x-flespi-cid: 11, e.g. 

curl -X GET --header 'x-flespi-cid: 11' --header 'Authorization: FlespiToken ABC’ 'https://flespi.io/gw/devices/all'

Important note: subaccount ID is the number containing inside it's "id" property, while "cid" property for any flespi object contains the ID of its parent's account. I.e. for subaccount "cid" equals to customer's owner_id. So you need to use value inside "id" field of subaccount to operate on its level.

MQTT API

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.