To your first question:
I am suggesting that a master access token to control all product devices is likely not possible I don’t believe an access token generated via OAuth client credentials without a customer scope would allow you to call functions / check variables on devices (This endpoint is documented here, you’d just leave out the scope).
We do this as a security measure to avoid a compromised token giving access to an entire fleet of devices. Using customers allows you to generate customer-scoped access tokens which do have the rights to call functions and check variables on devices belonging to the customer (i.e. a small subset of the fleet).
The only way for a master access token to be possible is to claim all devices to the same account (user account or customer account). That way, any access token generated for that account would have access to do anything and everything on devices in the fleet. We have had product creators take this approach.
With this approach, what you gain in flexibility and control you lose in security. That single access token would have tremendous power, and, if compromised, could leave you in a bad situation. You would have to be sure that you would never use this access token in a client-side application like a mobile or web application, or expose it anywhere outside your server.
To your second question:
Shadow customers were built with the assumption of using an email as the username. However, as long as you are not using the customer password resetting functionality exposed by the console, I can’t think of a reason why using a UUID would be a problem.
Hope this all makes sense.
