Matching entities from Account Management and other APIs

Finally we found a solution:

When having customers aka sub-tenants under your main-tenant, one has to make a token exchange for receiving status data for the specific customer.

Here is a post from Stanislav Pavlov how to do this.

So all we did was to fetch resources and resource status for each customer separately, with a bearer token of this specific customer.

Just another question: Will this behavior change with the next API changes?

Hello Sascha,

The responses from some endpoints (mostly GET methods) from our Tasks API, Agents API and Resource and Policy Management API should have the "tenant" section holding the User's UUID and User's name which are associated with certain devices/plans/backups in a customer's Cyber Protection Console.

"tenant": {
"id": "XXXXXXX",
"name": "XXXXXXXXXX",
"locator": "/X/XXXXXXX/XXXXXXX/"
}

Note that we use the "tenant" term for the users entities as well. Users have personal_tenant_id which is different from the user's UUID, and customer tenant's tenant_id.

To associate with the customer tenant you should use the Account Management API v1 api/1/users/{user_uuid} endpoint with UUID of this user obtained from that "tenant" section. GET api/1/users/{user_uuid} will retrieve all information about the user associated with backups, resources, etc., including the customer tenant where it resides. From the response you will find the "group" attribute holding the old Group ID of the customer tenant. Using GET api/1/groups/{group_id} with the Group ID from previous response, you will retrieve details of the customer tenant, including its long integer Tenant ID under the "uuid" attribute. This "uuid" (which in API v2 we call "tenant_id") can be used as well with Account Management API v2 GET api/2/tenants/{tenant_id} endpoint to get the customer tenant details alternatively.

I would appreciate if you could confirm that shared solution resolved the issue.

Stas Pavlov's approach is a good technique as well.

To your additional question, for the moment there are no plans for changing this behavior.