What Belongs in Imou OpenSDK and What Belongs in Your Backend

#camera #automation

Imou's own application-development documentation draws the line explicitly. Four things belong to the client SDK: device network configuration, device initialization, audio and video playback, and picture decryption. Everything else — account binding, device binding and unbinding, device management, device operation, cloud storage management and alarm message management — Imou recommends you call as HTTP interfaces from your own backend service.

Why this is the first architecture decision, not the last

Teams usually discover this boundary the expensive way. Someone gets a demo working end to end inside the mobile app, ships it, and then finds that the app is holding an administrator credential, that device management logic is duplicated across iOS and Android, and that every business rule change requires an app-store release.

The Imou documentation removes the guesswork. It does not describe the SDK as an optional convenience layer over the HTTP API. It describes a split of responsibilities, with a short list of functions on the client and an explicit recommendation that the rest goes through your background service.

Getting this right on day one costs nothing. Getting it wrong costs a re-architecture.

The documented split

Responsibility	Where the docs put it	Why it lands there
Device network configuration (provisioning)	Client SDK	Needs local network and radio access on the handset
Device initialization	Client SDK	Part of the same on-device onboarding flow
Audio and video playback	Client SDK	Media path; the docs state video preview does not require an HTTP interface call
Picture decryption	Client SDK	Alarm images are not plain files; the platform ships the decryption path
Account binding	Your backend (HTTP)	Identity, not a device operation
Device binding / unbinding	Your backend (HTTP), with SDK assistance where required	See the binding caveat below
Device management	Your backend (HTTP)	Your ledger is the source of truth
Device operation	Your backend (HTTP)	Must be gated by your own permission model
Cloud storage management	Your backend (HTTP)	Commercial and entitlement-bearing
Alarm message management	Your backend (HTTP)	Feeds your pipeline, not a phone

The same responsibility list appears on the desktop application-development page, so this is a platform-level pattern rather than a mobile-only quirk.

Token acquisition sets the pattern

The documented flow is unambiguous: the developer's background service calls the open platform to obtain the token. It is the first of the four core functions the guide walks through — obtain token, device binding, device list acquisition, video preview.

That ordering is the whole architecture in miniature. The credential is minted server-side, and the client only ever receives something scoped and short-lived.

You can see the same shape in the interfaces themselves. getKitToken, documented on the JavaScript SDK page, takes an administrator accessToken as input and returns a kitToken with a permission type — all permissions, live view, video playback, or PTZ rotation. The kitToken has a two-hour validity and the docs recommend caching it for one hour in your own service rather than re-requesting it every time.

So the pattern is: appId + appSecret never leave your backend → your backend holds accessToken → your backend mints a narrow, short-lived credential → the client gets only that.

Recommendation (mine, not a documented Imou requirement): treat getKitToken's permission type as a real authorization decision, not a constant. If your product has a watch-only role, mint live view rather than all permissions. The parameter exists precisely so that different end users can be given different permissions.

The binding exception you must design for

bindDevice is an HTTP interface, so by the table above it belongs on your backend. There is a documented caveat.

The mobile guide states that Imou has raised the security level of its devices, and that on subsequent new devices — or older devices upgraded to newer firmware — it may not be possible to complete binding by calling the HTTP bindDevice interface directly. Developers need to complete binding in conjunction with the client SDK. The guide also notes that binding involves several processes and that the flow differs by device version, with the detail carried in the client SDK DEMO.

Two consequences for your design:

Binding is a collaboration, not a single call. Model it as a flow that can involve the handset, not as one backend request that either succeeds or fails.
Do not generalise in either direction. This is version-dependent behaviour. Writing "binding always needs the SDK" is as wrong as assuming the plain HTTP call will always work. Build the SDK-assisted path and let the device version decide.

Sub-accounts are where the two halves meet

The documentation describes the pattern directly: an administrator account creates multiple sub-accounts, allocates device resources and permissions to each, and each sub-account is associated with a user in the developer's application.

That is the join between Imou's authorization model and yours. Your backend owns the mapping. The client should never be the thing that decides which devices a user can see.

You can verify the boundary is real by reading the interface pages. getCloudRecords, for example, documents its minimum sub-account permission as RecordReplay on a cam: resource, and accepts either an administrator or a sub-account token — while bindDeviceLive and getKitToken require an administrator accessToken. Interfaces that require admin rights are, by definition, interfaces your client must never call directly.

A reference flow

Backend obtains accessToken using appId and appSecret. Both stay server-side, always.
Backend creates the sub-account for your application user and allocates device resources and permissions.
Client SDK runs device network configuration and device initialization on the handset.
Backend + client SDK complete device binding together, following the version-specific flow in the SDK DEMO.
Backend queries the device list and writes it to your own ledger. Your ledger — not a live API call in a render loop — backs your UI.
Client SDK performs video preview. Per the docs this needs no HTTP interface call; you embed the SDK and follow the SDK instructions and DEMO.
Backend handles device operation, cloud storage management and alarm message management, each gated by your own permission model before the platform call is made.
Client SDK decrypts alarm images where your product displays them.

Pitfalls

Shipping appSecret or an administrator accessToken in an app binary. Anything that requires an administrator token is a backend responsibility by construction.
Assuming plain bindDevice is enough. Build the SDK-assisted path.
Duplicating device-management logic in iOS and Android. The docs recommend the backend for exactly this reason: one implementation, one place to change it.
Treating capability as universal. Playback, talk, PTZ and alarm images depend on the device and the subscribed services. Query, don't assume.
Skipping the ledger. Device management belongs to your backend, which means you should have a durable record, not a cache of the last list call.

DEV Community