Admin Token vs Sub-Account Token on Imou Open Platform

Use an administrator accessToken for application-level administration such as sub-account management, device binding, callback configuration, and cloud-storage activation where the interface page requires it. Use a sub-account accessToken for an application user’s permitted device operations when that interface explicitly accepts it. The minimum permission and resource on each live interface page are authoritative.

Why It Matters

Passing one administrator token through every user workflow collapses isolation: a leaked credential can expose the application’s broader device pool and administrative functions. Passing a sub-account token everywhere also fails because some interfaces are administrator-only. Design the token choice per operation, not by convenience or by a token’s shared field name.

The account model connects each user in your application to an Imou sub-account and assigned device resources and permissions. Your application still owns user authentication, tenant membership, and the decision to issue a permitted operation.

Architecture

Your end user
  -> your authenticated application / BFF
       -> your tenant and role check
       -> sub-account token for permitted device action

Your trusted control plane
  -> administrator accessToken
       -> create/manage sub-accounts and policies
       -> bind/unbind devices
       -> configure callbacks
       -> activate applicable cloud storage

Keep appSecret and administrator tokens on trusted backend systems. A sub-account token is narrower only when its policies are narrower; it is still sensitive and should not be logged or shared across users.

Operation	Token rule shown by current documentation
Obtain administrator token through accessToken	Uses application appId and appSecret; returns administrator accessToken
Create/delete/list sub-accounts, issue sub-account token, add/clear/query permissions	Account-administration flow begins with administrator authority; check each interface
subAccountToken	Request requires administrator accessToken plus sub-account openid; returns sub-account accessToken
bindDevice	Interface requires administrator accessToken
setMessageCallback	Interface requires administrator accessToken
openCloudRecord	Interface requires administrator accessToken
getAlarmMessage	Accepts administrator or sub-account accessToken; page states minimum sub-account Alarm permission on the channel resource

This table is illustrative, not a global permission matrix. For every method, the current interface page wins.

Implementation Steps

1. Map each product user to one controlled identity. Create or look up the applicable Imou sub-account and store its openid against your internal user or service identity.
2. Define least-privilege resources and permissions. Grant only the devices/channels and documented permission names needed for that role. Do not invent permission labels.
3. Keep the administrator control plane separate. Restrict jobs that bind devices, manage sub-accounts, change policies, configure pushes, or activate storage. Do not expose those routes directly to a browser.
4. Obtain sub-account tokens server-side. subAccountToken requires an administrator token and openid. Return or use the resulting credential only within the narrow application flow that needs it.
5. Check the target interface page. Confirm whether it accepts administrator, sub-account, or only administrator tokens and note the exact minimum sub-account permission/resource when provided.
6. Enforce your own authorization first. Imou policies do not replace tenant, site, role, approval, and offboarding rules in your product.
7. Revoke access through lifecycle controls. Clear or change policies and delete sub-accounts when appropriate; invalidate your own sessions and cached credentials according to your security design.

APIs and Official Documentation

• Account docking: lists sub-account creation, deletion, lookup, token, policy, permission, and device-list interfaces.
• accessToken: obtains the administrator token from application credentials on the backend.
• subAccountToken: takes an administrator token and openid, then returns a sub-account accessToken.
• bindDevice: documents an administrator-token requirement.
• setMessageCallback: documents an administrator-token requirement.
• openCloudRecord: documents an administrator-token requirement for cloud-storage activation.
• getAlarmMessage: accepts administrator or sub-account tokens and documents the minimum sub-account Alarm permission for a cam: resource.

Limits and Pitfalls

Do not identify token type by parameter name alone. Multiple interfaces call the parameter token, and both credentials can be described as accessToken. Authority comes from how the token was issued and what the target interface allows.

Do not assume a sub-account can call every device API. The interface must accept sub-account tokens, and the sub-account must have the documented permission on the correct resource.

Do not assume administrator is a harmless fallback. Using an administrator token to bypass a missing policy hides authorization defects and expands breach impact.

Do not treat Imou authorization as your SaaS ACL. Your backend must first verify user, tenant, site, role, and device mapping. Platform permission is a second boundary.

Do not put appSecret or administrator tokens in clients. Browser storage, mobile configuration, frontend environment variables, crash reports, and client logs are not safe control-plane stores.

Do not cache across identities. Index sub-account tokens by the correct identity and authorization context. Never reuse one user’s token for another.

Do not rely on a static article for every interface forever. Permission requirements can be interface-specific. Recheck the live page during implementation and human QA.

Do not invent token guarantees. This article does not claim universal expiration, refresh, revocation propagation, SLA, or error codes beyond the linked interface documentation.

Decision Rule

Ask two questions before every OpenAPI call:

1. Is this an application/account/control-plane action whose interface requires an administrator token?
2. If it is a user-scoped device action, does the interface explicitly accept a sub-account token, and does that sub-account hold the stated permission on the stated resource?

If either answer is unclear, stop and read that interface’s “Incoming parameter” and “Minimum permissions required” sections. Do not test by sending the broader credential first.

Register at Imou Open Platform to evaluate its cloud-video and AIoT account, device, storage, and event APIs, then build token selection from the current per-interface permission documentation.