Yeah, it does clarify, cheers!
I think at this point resin.io assumes that a single “fleet” is under a single access, thus if you have access to one device, then you’d have access to all in the same application. Thus technically, if you keep one application for all the devices, the client separation is indeed needed to be done in your overlay system/database - for example keeping lists of UUIDs associated with the different users, and create access control for your clients based on that.
A bit more complex setup would probably be creating a separate application for each customer. That way you can have finer control over the devices as well, and they are more “firewalled” between each other as well. In that case IMHO you would still need to use your own system/database, while e.g. associating the application ID with the specific customer.
But that’s all on your side, each device has it’s own set of environment variables and you could apply configuration to each device as you see it fit. To automate that, maybe keeping track of the device UUIDs for each customer and using the API to update env vars would enable you to have sufficient separation whether it’s one application or one-application-per-customer approach you take.
If you are not giving access to your clients on resin.io directly, but always through your site/service, then you have a lot of leeway regarding how to manage your applications, devices, and associated data.
Is this any help?