Account and authorization
Account and authorization
This section covers who calls the OpenAPI (administrator, sub-account, OAuth user) and how app users get device permissions. Device hosting / warrant flows are not published for overseas integrations.
Background: Sub-accounts and policies, OAuth 2.0 authorization, Tokens. Request fields live on Account and authorization APIs.
Tasks in this section
| Task | When to use it |
|---|---|
| Set up a sub-account | Your SaaS user must operate devices under your developer account; Policy, permissions, subAccountToken |
| OAuth for user devices | End users sign in with Imou and grant devices to your app; complements the sub-account model |
| Configure flow resource pools | Cap playback traffic per sub-account or device channel |
Server vs client
- Sub-accounts: Create accounts, assign permissions, and exchange tokens only on a trusted server; never ship AppSecret or long-lived tokens to browsers or untrusted clients.
- OAuth: Authorization code and refresh on the server; mobile/light apps receive short-lived tokens or kitToken (see Build a mobile app, Integrate the light application).
- Device list and bind stay on Device management APIs; sub-account visibility follows permissions.
Prerequisites
Create an application with AppId / AppSecret; first HTTP call: First API call.