DEV Community: Imou-OpenPlatform

Imou Open Platform Production Checklist: Devices, Events, Permissions and Storage

Imou-OpenPlatform — Tue, 01 Sep 2026 07:11:07 +0000

Before production, prove one complete lifecycle with the actual account region, devices, firmware, services, and client: signed backend access, supported onboarding and binding, device/channel inventory, least-privilege authorization, callback HTTP 200 and downstream processing, optional media behavior, storage queries, live-address controls, credential protection, observability, offboarding, and recovery. Documentation establishes interfaces; your pilot must establish that the selected combination works.

Why it matters

Most integration demos prove only a happy-path frame or successful API response. Production failures happen between those moments: a device generation needs an SDK-assisted binding path, a callback route returns a redirect, an event has no image, a sub-account lacks channel permission, or a live address is paused. A production gate should test transitions and boundaries, not simply count completed endpoints.

The Imou homepage groups the platform into device access, video security, value-added services, app development, Home Assistant, and SaaS-oriented management. Use that map to identify dependencies, then use live method documentation and deployment evidence for approval.

Approach / architecture

Assign an owner and proof artifact to each plane:

Plane	Production proof	Owner
Credentials and region	Console assignment, signed test, secret controls	Platform/backend
Device onboarding	Supported state transitions on target versions	Mobile/device/backend
Inventory	Device/channel/capability reconciliation	Backend
Authorization	Allowed and denied user/resource tests	Security/backend
Events	Public callback, exact 200, durable processing	Backend/operations
Evidence and storage	Snapshot/video query and missing-media UX	Product/backend
Live operations	Address, plan, and status runbook	Operations
Client	Verified mobile, PC, browser, or HA workflow	Client team
Lifecycle	Credential rotation, device removal, user offboarding	Security/operations

Keep AppSecret, administrator tokens, signing, and administrative OpenAPI calls in a trusted backend. Place only documented client responsibilities in OpenSDK or web components. Your product owns tenant authorization even when Imou sub-account permissions are also used.

Seven production gates

Prove application identity and regional routing. Record the data center assigned in Control Board and map the credential set to the documented SG, FK, or OR endpoint. Run the official signing test and a real signed request. Reject unknown region config at startup.
Prove onboarding for supported combinations. Test network configuration, initialization, binding, resume after interruption, existing binding, and device removal with the device and software versions you will support. Follow current OpenSDK demos where SDK-assisted binding is required.
Prove inventory and capability decisions. Reconcile every bound device and channel into your product model. Drive controls from returned capabilities and services, not a universal model promise. Test offline and unsupported states.
Prove least privilege. Classify every method by administrator versus sub-account token. Test the minimum documented resource and permission, wrong tenant, wrong channel, removed policy, and attempts to invoke administrator work through user routes.
Prove callback recovery. Verify the public URL, TLS, exact HTTP 200, durable enqueue, family-specific parsing, duplicate handling, and downstream failure isolation. Test saved callback configuration and a re-subscription runbook without inventing retry counts.
Prove evidence, storage, and live behavior. Render events without images, process images only where present, test snapshot and video queries where subscribed, and operate live addresses using exact address-, stream-, and plan-state fields. Do not assume entitlement or media completeness.
Prove operations and offboarding. Build redacted diagnostics, alert ownership, controlled config changes, user removal, device unbinding, live-address cleanup, credential rotation, and rollback. Run an incident exercise before scaling.

APIs / SDKs

Start at the Imou Open Platform homepage for the product map. Use the following current sources as implementation boundaries:

HTTP development specification for regional endpoints, request envelope, and signatures;
mobile application guide for SDK/backend responsibility and version-dependent binding;
account docking for sub-accounts and policies;
event push process and event formats;
getCloudRecords for snapshot/video record queries;
live module for address and plan lifecycle; and
the verified PC guide and docking-mode comparison when evaluating desktop.

Method pages win over summaries. Save the source and review date in each production control.

Required test evidence

For each gate, retain environment, application reference, account region, device and software version, SDK/client version, method, sanitized request ID and result, expected outcome, observed outcome, and reviewer. Never include AppSecret, full access tokens, device passwords, verification codes, signed media URLs, reusable live addresses, or unredacted customer payloads.

Evidence should distinguish documented fact from application policy. For example, HTTP 200 is a documented callback requirement; your queue, timeout, retry, deduplication, and alert thresholds are internal design. liveStatus values are documented; your incident severity and remediation are internal policy.

Release and rollback

Release first to a small, known inventory. Confirm onboarding, one permitted user flow, one denied flow, one callback event, one media-absent event, one storage query where applicable, and one controlled live-state observation. Expand only after logs and support tools can explain each stage.

Rollback must preserve authorization and evidence. Define how to disable a client feature without exposing broader credentials, restore callback routing, revert endpoint config, and reconcile any device, policy, or live-address writes made during deployment.

Limits & pitfalls

Do not approve production from one successful live frame.
Do not promise all models, firmware, events, images, storage, playback, talk, PTZ, or client features.
Do not expose AppSecret, administrator tokens, sub-account tokens, signed images, or live addresses.
Do not select regional endpoints from end-user geography or infer data residency from hostname labels.
Do not invent callback retry counts, platform latency, implementation duration, or SLA.
Do not publish prices, storage unit costs, entitlement quantities, or universal retention from technical pages.
Do not invent AI endpoints or promise AI results.
Do not use administrator authority as a fallback for failed user-scoped calls.
Do not use guessed /book/en/pc/ paths; the verified PC guide is /book/pc/summary.html.
Recheck live documentation on release and publication day.

Go/no-go record

The final record should name unresolved risks. “Not tested” is a no-go for a required journey, but it can be an explicit non-feature for out-of-scope capabilities. Document supported combinations narrowly, give users honest unavailable states, and create a revalidation trigger for SDK, device software, account region, service, endpoint, or callback changes.

Use Imou Open Platform to assemble a one-device production rehearsal, and promote only after every required lifecycle gate has current, sanitized evidence.

Operate Imou Live Addresses Using Status, Plans and Insufficient-Traffic Signals

Imou-OpenPlatform — Tue, 01 Sep 2026 07:09:46 +0000

Operate live addresses with two separate status vocabularies. Current liveList documentation defines address-level liveStatus as 1 open, 2 pause, and 3 insufficient traffic. Current queryLiveStatus returns stream-level status: 0 live, 1 live with abnormal cover, 2 abnormal video source, 3 abnormal stream conversion, 4 abnormal cloud-storage access, and 10 paused. Preserve these exact values and inspect plan state separately.

Why it matters

A live URL existing in a database does not mean it is usable. The address can be paused, a schedule can be disabled, or an individual stream can report a source or conversion problem. If an operations system collapses all those states into healthy: true/false, it cannot route incidents or explain why viewers see no video.

There is a second trap: 3 means different things in different fields. Address-level liveStatus: 3 in liveList is documented as insufficient traffic. Stream-level status: "3" in queryLiveStatus is documented as abnormal stream conversion. Field name and source method are part of the meaning.

Approach / architecture

Maintain a live-address ledger keyed by liveToken:

Ledger field	Source	Purpose
Address identity	`liveList` / creation response	Stable lookup for lifecycle operations
Device and channel	`liveList` or `getLiveStreamInfo`	Asset relationship
`liveStatus`	`liveList`	Address-level state
Stream `status` by `streamId`	`queryLiveStatus`	Per-stream technical state
`job.status`, period, begin/end	`liveList`	Plan snapshot
Last observed time and method	Your backend	Freshness and diagnostics
Redacted address reference	Returned stream data	Controlled playback handoff

This schema is recommended operator design, not an Imou-prescribed database. Restrict full HLS/RTMP addresses as secrets or sensitive operational data.

Exact current status vocabularies

Address-level `liveStatus` from `liveList`

Value	Current documentation label
`1`	Open
`2`	Pause
`3`	Insufficient traffic

Stream-level `status` from `queryLiveStatus`

Value	Current documentation label
`0`	Live broadcast
`1`	Live broadcast, but the video cover is abnormal
`2`	Video source is abnormal
`3`	Stream conversion abnormal
`4`	Cloud storage access abnormal
`10`	Live broadcast is paused

These labels reflect the current live pages reviewed for this draft. They must be checked again on publication day. Do not transform nonzero values into one generic failure before storing the raw field and method.

Seven operational steps

Inventory created addresses. Call liveList with its documented range and paginate through the intended account scope. Record liveToken, device/channel where present, type, streams, liveStatus, and job.
Reconcile with your asset ledger. Identify addresses with no owning product record, assets expecting an address that is absent, and duplicate assumptions. Do not delete or recreate automatically before confirming ownership.
Read plan state independently. The returned job includes status and schedule information. A paused or out-of-plan experience is not automatically a stream-source incident. Preserve the values exactly and check the applicable plan method before writing changes.
Drill into stream state. For active or important addresses, call queryLiveStatus by liveToken. Save status per streamId; do not overwrite address-level state.
Route by documented category. Open, paused, insufficient-traffic, cover, source, conversion, storage-access, and stream-paused observations need different operator queues. The action and alert threshold are your policy.
Protect playback data. Return live addresses only after product authorization, avoid persistent client exposure where possible, and redact them from normal logs, dashboards, tickets, and screenshots.
Recheck after controlled change. Use documented methods such as modifyLivePlanStatus, modifyLivePlan, or batchModifyLivePlan only through an approved backend workflow. Read state again and record the result.

APIs / SDKs

The live module summary lists the live-address lifecycle:

bindDeviceLive creates a device-source live address;
unbindLive deletes a live address;
liveList inventories addresses and address-level state;
queryLiveStatus inspects stream-level state;
modifyLivePlanStatus, modifyLivePlan, and batchModifyLivePlan manage plans;
getLiveStreamInfo resolves live information by device and channel; and
RTMP methods create, delete, and query RTMP live addresses.

The current liveList and queryLiveStatus pages require administrator accessToken. Keep it in the trusted backend. Method existence does not guarantee a live result for every device, channel, codec, account, region, or service.

Observability and incident records

Every sample should retain method name, request id, account region, redacted liveToken, device/channel reference, raw documented status, stream ID where applicable, plan snapshot, and observation time. Separate API-call failure from a successful response that reports a non-healthy state.

Do not label liveStatus: 3 with a price or billing conclusion. The verified statement is only the current page’s “insufficient traffic” label. Commercial interpretation, entitlement, replenishment, and account action require approved current sources.

Limits & pitfalls

Never merge liveStatus and stream status; their value 3 has different meanings.
Do not invent status values or rename them into unsupported diagnoses.
Do not treat liveStatus: 1 as proof that every stream variant is healthy.
Do not treat job.status as the same field as live or stream status.
Do not infer timezone or recurrence semantics without reading the live plan-method page.
Do not expose reusable live URLs, live tokens, administrator tokens, or AppSecret.
Do not automatically recreate an address when status is abnormal; first preserve evidence and ownership.
Do not invent pricing, quota quantities, SLA, recovery timing, or universal account actions for insufficient traffic.
Do not promise every device supports every live protocol or stream.
Revalidate all values and method permissions immediately before publication.

Use the current Imou live module documentation to build a status-aware ledger, then test each operator branch with a controlled live address.

Desktop Private Protocol vs Browser Integration on Imou Open Platform

Imou-OpenPlatform — Tue, 01 Sep 2026 07:09:15 +0000

Choose PC OpenSDK when a managed desktop application needs the documented desktop private-protocol capabilities: real-time preview, recorded-video playback, voice intercom, and device control. Choose cloud live in a browser when the job is primarily HLS preview and sharing. The desktop guide still assigns accounts, devices, storage, alarms, and token work to a backend. Verify current capabilities and use only the confirmed PC documentation path.

Why it matters

“Desktop versus web” sounds like a packaging decision, but it is really a workflow and responsibility decision. An installed operator console can justify native integration when talk, playback, and operational interaction matter. A browser page can be easier to distribute when users only need to view a live feed. Choosing PC OpenSDK solely because it appears more capable can add deployment and maintenance work without solving a real user need.

The comparison must also avoid an inaccurate shortcut: browser integration is not necessarily one feature set. The official docking-mode page compares desktop application docking with cloud live broadcast docking. This article limits its detailed comparison to that verified table and does not invent capabilities for undocumented paths.

Approach / architecture

Evaluate three layers independently:

Layer	PC OpenSDK path	Browser cloud-live path
Client deployment	Installed, managed desktop application	Web or H5 delivery
Media protocol in docking table	Private protocol	HLS
Table capabilities	Preview, playback, voice intercom, device control	Preview; playback and intercom not supported in that row
Backend requirement	Required for token, inventory, account/device/storage/alarm work	Required for credentials, authorization, and live-address lifecycle
Product fit	Operator workstation	Viewing, sharing, lightweight access

The current docking-mode table marks device configuration as not supported for desktop application docking. Do not equate “native client” with every platform function. The PC application guide recommends backend HTTP calls for account binding, device binding/unbinding, device management and operation, cloud storage, and alarm messages; audio/video playback uses the client SDK.

Six decision and implementation steps

Write the operator task. Specify whether users only watch, or must also review recordings, talk, and control devices. Identify managed workstations, browser-only users, and support constraints.
Match required capability to verified documentation. Use the live docking-mode table for private-protocol desktop versus HLS cloud live. Do not infer additional controls because a client is native or because another SDK exposes them.
Design the backend first. Keep AppSecret, administrator tokens, signed OpenAPI calls, product authorization, account/device operations, storage, and event handling in trusted services. Both client choices depend on this boundary.
Prototype with the current PC package or live path. For PC, follow the current OpenSDK demo and confirmed guide at https://open.imoulife.com/book/pc/summary.html. For browser cloud live, create and protect the documented live address through the backend.
Test the whole operator workflow. Include sign-in, device selection, preview, applicable playback/talk/control, offline devices, revoked access, workstation updates, and user offboarding. Measure your own environment without publishing an Imou SLA.
Record the decision and fallback. State which verified capability justified native installation, how the backend authorizes it, and what browser users can do. Reassess if the requirement or current documentation changes.

APIs / SDKs

Use only these verified PC-related sources:

Select docking mode, the canonical comparison of mobile, cloud live, and desktop docking; and
PC application development, the confirmed desktop guide path.

Do not invent or publish a /book/en/pc/ route. It was not verified. The PC guide describes three core stages—getting a token, getting a device list, and video preview—and assigns audio/video playback to embedded OpenSDK while recommending backend HTTP interfaces for the remaining management functions.

For cloud live operations, consult the live module summary for documented address creation, listing, status, plan, and removal methods. Treat live addresses as sensitive operational data and authorize their distribution.

A client-boundary blueprint

Operator
  -> PC OpenSDK client OR browser
       -> your authenticated backend
            -> tenant/role/device authorization
            -> regional Imou OpenAPI
            -> device inventory and live lifecycle
       -> documented media path

Callback ingress
  -> durable event pipeline
  -> authorized operator workflow

This blueprint keeps client choice from controlling account security. A PC app must not ship AppSecret; a browser must not receive administrator tokens. Local caches, logs, crash reports, screenshots, and support bundles should redact tokens, device credentials, and reusable live URLs.

Operational questions before choosing PC

Can the organization deploy and update a native application? Are operators on managed machines? Does the workflow truly require playback or intercom in the same console? How will permissions be revoked when an operator changes roles? What happens when a device is offline? Can support reproduce the issue without collecting secrets? Is the target device capability confirmed?

If those questions have weak answers, the richer client may create an operations problem. If the workflow requires documented desktop capabilities and native deployment is normal, PC OpenSDK can be the appropriate surface.

Limits & pitfalls

Do not use or guess /book/en/pc/ links. Use the confirmed /book/pc/summary.html.
Do not quote docking-time figures. The English table renders wording that should not be reused.
Do not quote performance or latency numbers in this draft; publication would require opening and revalidating the live page on that date.
Do not claim cloud live represents every possible browser component or capability.
Do not claim desktop supports device configuration; the current comparison marks it unsupported.
Do not move account, token, storage, alarm, or authorization control into the client.
Do not promise playback, talk, control, codecs, or model coverage for every device.
Do not infer price, SLA, data residency, or universal compatibility from the comparison.
Do not publish full live addresses or credentials in logs and examples.
Recheck both verified pages and the current SDK package before release.

Compare the live docking modes at Imou Open Platform, then prototype the smallest client that satisfies the verified operator workflow.

Configure Imou Regional Endpoints: Singapore, Frankfurt and Oregon

Imou-OpenPlatform — Tue, 01 Sep 2026 07:08:43 +0000

Configure the OpenAPI base URL from the data center assigned to the developer account in Control Board → Basic Information → My Information. Current documentation maps East Asia to openapi-sg.easy4ip.com, Central Europe to openapi-fk.easy4ip.com, and Western America to openapi-or.easy4ip.com, using HTTPS POST under /openapi/[method]. Do not choose by end-user location or infer data residency from these labels.

Why it matters

Regional routing is part of credential identity, not a frontend performance setting. A correctly signed request sent to the wrong regional host can fail or address the wrong platform context. Teams often hide this mismatch by rotating secrets, changing signature code, or adding fallback hosts, which makes diagnosis harder and can mix operational records.

The console assignment wins. Geographic proximity, browser locale, customer country, and deployment cloud region are not documented selectors. Endpoint labels also do not establish where all data is stored, replicated, backed up, or processed.

Approach / architecture

Bind each application credential set to one immutable regional configuration:

Config key	Example value	Rule
`IMOU_REGION`	`east_asia`	Controlled enum matching console assignment
`IMOU_BASE_URL`	`https://openapi-sg.easy4ip.com:443/openapi`	Derived from reviewed mapping
`IMOU_APP_ID`	Secret-backed reference	Paired with one region
`IMOU_APP_SECRET`	Secret manager reference	Backend only
`SOURCE_REVIEWED_AT`	Release metadata	Triggers documentation review

The application should reject unknown or incomplete region configuration at startup. It should never accept a base URL from a browser, customer request, device payload, or general-purpose redirect. If multiple Imou applications are legitimate, partition credentials, region, logs, quotas, and reconciliation jobs by application.

Current documented mapping

The live development specification lists:

Data center label	HTTPS POST pattern
East Asia Data Center	`https://openapi-sg.easy4ip.com:443/openapi/[method]`
Central Europe Data Center	`https://openapi-fk.easy4ip.com:443/openapi/[method]`
Western America Data Center	`https://openapi-or.easy4ip.com:443/openapi/[method]`

Use the method name from the applicable interface documentation. Preserve HTTPS and the /openapi/ path. These are international Open Platform mappings; do not silently mix them with a different portal or China-region configuration.

Six configuration steps

Identify the owning developer application. Confirm the appId used by this deployment and which team controls it. Avoid selecting region from a device or end-user profile.
Read the console assignment. Sign in to the corresponding account and open Control Board → Basic Information → My Information. Record the displayed data center as controlled deployment evidence.
Map assignment to the live documented host. Use the current development specification, not a hostname copied from an old project or search result. Add an explicit enum rather than a free-form URL.
Pair region and credentials in secret-backed configuration. Deploy them as one reviewed unit. Prevent one environment from loading an appId from one region and a base URL from another.
Run a signed backend test. Use the documented request envelope and signing procedure. Record request id, selected region, method, and sanitized result; never log appSecret, full tokens, or signing source strings containing secrets.
Promote with drift checks. Compare the deployed region enum, derived host, and credential reference across environments. Recheck the live mapping before publication and when onboarding another developer application.

APIs / SDKs

The HTTP development specification is canonical for regional hosts, request structure, response structure, and signature calculation. Each HTTPS request contains a system block with protocol version, appId, signature, time, and nonce, plus a unique non-empty request id and method parameters.

Regional configuration and signing should remain separate modules. The signer accepts a credential reference and request metadata; the transport accepts the region-derived base URL. This makes logs and tests show whether a failure arose before signing, during host selection, or in the method response.

Use the official fixed signature test case from the live specification to verify the signing implementation. Do not place its example secret into production. Do not convert documentation time or nonce constraints into unrelated service latency or SLA claims.

Troubleshooting endpoint mismatches

Check in this order:

international portal and owning account;
console-assigned data center;
deployed region enum and derived host;
paired appId and secret reference;
exact /openapi/[method] path;
UTC request time, nonce, request ID, and signature implementation;
method parameters and token authority.

Keep the original sanitized result and request ID. Do not automatically retry against all regional hosts. A “first host that succeeds” strategy turns configuration mistakes into cross-region ambiguity and may conceal an incorrect credential inventory.

When support receives a region-related incident, include environment, application reference, console assignment evidence, configured enum, hostname, method, UTC time, and redacted result. Exclude the secret, complete signature input, and reusable token.

Limits & pitfalls

Do not select a regional endpoint from customer IP, browser locale, DNS latency, or device location.
Do not implement automatic cross-region failover unless an official, approved architecture explicitly defines it.
Do not mix international and China portal credentials or hosts.
Do not infer data residency, replication, disaster recovery, compliance coverage, or SLA from sg, fk, or or.
Do not expose base-URL choice as an end-user setting.
Do not keep region independent from its credential set.
Do not rotate credentials before ruling out a host mismatch.
Do not log AppSecret, administrator tokens, full signatures, or sensitive params.
Do not claim that one successful API test proves all device and service capabilities.
Recheck the console path and documented mapping before publication and every new rollout.

Treat endpoint configuration as reviewed infrastructure code. Changes should state old and new assignment, credential owner, source reviewed, validation method, and rollback. An endpoint edit is not a harmless URL change; it affects every signed API call made with that application identity.

Inspect your application’s assigned data center at Imou Open Platform and validate one signed backend call against the matching documented endpoint before enabling device workflows.

Retention Design for Imou Cloud Snapshot vs Cloud Video Storage

Imou-OpenPlatform — Tue, 01 Sep 2026 07:08:07 +0000

Choose snapshots when one still image is sufficient for triage or event verification; choose video when the workflow must reconstruct sequence, motion, duration, or surrounding context. Imou’s cloud-record query distinguishes cloudType: "snapshot" from "video". Make the decision per workflow and validate device and service availability. The API page does not establish public unit pricing, universal retention, or support for every channel.

Why it matters

Retention is a product decision disguised as a storage toggle. A snapshot may show that something was present but not how it arrived or what happened next. Video can provide context, but it also changes review, access, privacy, and deletion requirements. Defaulting every event to the richest medium can retain unnecessary material; defaulting to still images can leave investigators unable to answer the incident question.

The correct comparison starts with evidence and users, not speculative cost. The cited technical page defines query behavior, not commercial terms. Pricing, package availability, and contractual retention must be confirmed through the applicable account and approved source.

Approach / architecture

Separate four decisions:

Decision	Snapshot-oriented answer	Video-oriented answer
Evidence question	“Was a visible condition present?”	“What happened across time?”
Review experience	Fast visual triage	Timeline or clip review
Access surface	Event card or verification queue	Incident player and controlled export
Data governance	Still-image policy	Video policy with broader contextual content

Then keep the media path behind the same authorization boundary:

event or incident request
  -> product tenant/role check
  -> device and channel scope
  -> choose evidence type for workflow
  -> getCloudRecords(cloudType = snapshot | video)
  -> authorized review experience

This is architecture guidance. It does not imply that one event has both formats, that one service includes another, or that all devices support both.

Six design and implementation steps

Write the decision the user must make. “Confirm a person appeared” may fit a still; “understand entry, action, and exit” generally needs a temporal record. Avoid vague requirements such as “keep evidence.”
Map the reviewer journey. Identify who can view media, which device/channel they may access, whether they need only triage or deeper investigation, and what action follows. Define a deliberate missing-media state.
Confirm actual service and device support. Test the target account, region, device, channel, and subscribed service. A method in the documentation is not proof that records exist for every deployment.
Query through a trusted authorization layer. Validate the product user and resource before calling the API. If a sub-account token is used, confirm the current method’s minimum permission and resource form. Keep administrator credentials off clients.
Select the documented media type. Call getCloudRecords with the required device, channel, time window, count, and applicable token. Use cloudType value snapshot or video; current documentation identifies video as the default.
Validate evidence and governance together. Run realistic review scenarios, permission denial, missing records, device offline conditions, user offboarding, and deletion/retention procedures. Record observed behavior without turning it into a universal platform guarantee.

APIs / SDKs

The canonical getCloudRecords page defines cloud-record retrieval and the cloudType selector. Use its live parameter and return-field tables rather than copying a stale sample into production.

Related official pages include:

queryCloudRecords, an additional cloud-record query path with its documented ordering;
the cloud storage interface summary, which maps service-management methods;
the account docking summary for administrator and sub-account design; and
the Imou Open Platform homepage for the distinction between Cloud Video Storage and Cloud Snapshot Storage.

Do not confuse cloudType with a returned recording type. The former selects snapshot or video media for the query; recording-type fields classify records according to that interface’s documentation.

Mixed retention can be intentional

A single product can use different evidence depth by workflow. A high-volume operations queue may show available snapshots for rapid triage. A confirmed incident can open available video for authorized reviewers. Another site may disable retained media for policy reasons. These are product choices conditioned on actual service availability.

Keep the event record independent from media. The event should retain its useful type, device/channel, time, and workflow state even when no snapshot or video is returned. This avoids turning temporary media unavailability into a lost event.

Use separate access logs for sensitive media. Record who requested which channel and time window, the product authorization decision, and the redacted platform result. Do not log reusable media addresses or credentials.

Retention review questions

Before rollout, ask:

Does the selected format answer the documented operational question?
Can the interface render a useful event when media is absent?
Are viewers limited by tenant, role, site, device, and channel?
Are exports more restricted than ordinary viewing where appropriate?
Are storage availability and service state checked rather than assumed?
Is deletion or expiration behavior understood from approved commercial and legal sources?
Does the support process avoid copying media into tickets and chat?

These are governance prompts, not statements about Imou service terms.

Limits & pitfalls

Do not publish unit prices, savings percentages, “free” entitlements, or package comparisons from the API page.
Do not claim a universal retention duration, unlimited availability, SLA, or data residency.
Do not assume every alarm has a snapshot or a corresponding video clip.
Do not treat one still as complete temporal context.
Do not treat a returned clip as proof that the entire incident window is covered.
Do not infer support from another model, account, region, or channel.
Do not mix cloudType with recording classification fields.
Do not send administrator tokens, signed media URLs, or sensitive record details to unauthorized clients.
Do not let storage selection replace consent, privacy, legal, and access review.
Recheck current parameter limits, ordering, permissions, and service documentation before publication.

A good decision record names the workflow, evidence question, chosen format, tested device/channel, required service, authorized roles, missing-media behavior, and the official source reviewed. It clearly labels pricing and contractual retention as unresolved until confirmed outside the technical API page.

Review the live getCloudRecords contract and test both evidence workflows with your authorized target devices before setting a retention policy.

Classify Imou HTTP Interfaces by Administrator vs Sub-Account Token

Imou-OpenPlatform — Tue, 01 Sep 2026 07:07:30 +0000

Classify token authority per interface, not by the shared parameter name token. Current Imou pages require an administrator accessToken for control-plane work such as issuing sub-account tokens, changing policies, binding devices, configuring callbacks, and managing live addresses. Some device-facing queries accept administrator or sub-account tokens when the sub-account has the documented permission. The target interface page is always the final authority.

Why it matters

Using an administrator token for every request makes development look easy but collapses isolation. A user-facing defect or leaked credential can then reach account-wide controls. The reverse shortcut also fails: a sub-account token cannot be assumed to call administrative interfaces simply because they accept a field named token.

Imou account permissions are one layer. Your product must still authenticate the user, establish tenant and role membership, map the requested device or channel to that tenant, and decide whether the action is allowed. Only then should it select the narrowest platform credential accepted by the method.

Approach / architecture

Separate two backend paths:

Path	Typical caller	Credential	Responsibilities
Control plane	Restricted service or approved operator	Administrator `accessToken`	Sub-accounts, policies, binding, callbacks, service/live administration
User operation plane	Authenticated product workflow	Sub-account token where accepted	Permitted device/channel action

Keep both credentials server-side unless a documented client flow specifically requires otherwise. A sub-account token is still sensitive. Its reduced impact depends on correct policies and resource scope, not on its prefix or storage location.

Create a machine-readable interface register with: method, source URL, accepted token types, minimum sub-account permission, resource form, owner service, and last review date. Reject calls for which authority is unknown rather than falling back to administrator.

A documentation-bounded classification

Interface or family	Current documented token rule	Use
`accessToken`	Application credentials obtain administrator token	Bootstrap backend authority
`subAccountToken`	Administrator token plus `openid`	Issue a sub-account token
Account administration (`createSubAccount`, `deleteSubAccount`, `addPolicy`, `clearPolicy`)	Administrator control-plane flow; verify each page	Identity and permission lifecycle
`bindDevice`	Administrator token	Bind device to account
`setMessageCallback`	Administrator token	Configure callback subscription
`liveList`, `queryLiveStatus`	Administrator token on current pages	Inventory and inspect live addresses
`getAlarmMessage`	Administrator or sub-account token; current page documents minimum sub-account permission	User-scoped alarm query when authorized
`listDeviceDetailsByIds`	Administrator or sub-account token on current page	Device detail query within allowed scope

This is an implementation starting point, not a complete permanent matrix. Review every method you use. Similar-looking methods can have different authority requirements.

Seven implementation steps

Inventory actual calls. Extract every OpenAPI method used by backend routes, workers, scheduled jobs, and support tools. Do not classify a broad module while missing one write method.
Open each live method page. Record whether the parameter accepts administrator only or administrator/sub-account. Where documented, capture minimum permission and whether the resource is device- or channel-scoped.
Map product identities. Associate each application user or service role with the intended Imou sub-account openid where that model applies. Never share one user’s cached token with another.
Grant least privilege. Use only documented policy names and exact dev: or cam: resource forms applicable to the operation. Keep policy creation and removal in the administrator control plane.
Build an explicit credential selector. The caller supplies an operation identifier and authorized application identity; the selector looks up the reviewed rule. It must not choose administrator merely because a sub-account call failed.
Enforce product authorization first. Validate tenant, site, role, device/channel mapping, and action. A platform permission should be a second gate rather than the only gate.
Test denial and offboarding. Verify allowed calls, missing permission, wrong resource, deleted or cleared policy, user removal, and attempts to invoke administrator-only methods through a user route.

APIs / SDKs

The account docking summary lists sub-account creation, deletion, listing, token, policy, permission, and device-list interfaces. It is the canonical source for the account module’s scope.

Important method pages include:

accessToken, which obtains the administrator token using application credentials;
subAccountToken, which requires an administrator token and openid;
addPolicy, an administrator-authorized policy write;
bindDevice, which requires administrator authority;
setMessageCallback, which requires administrator authority;
queryLiveStatus, whose current page identifies administrator accessToken; and
listDeviceDetailsByIds, whose current page accepts administrator or sub-account token.

Method documentation can change. Store the source beside the rule and recheck it during release QA.

Credential-selection pattern

Avoid code such as “try sub-account; on authorization error retry as admin.” That converts a denied user operation into an elevated operation. Prefer a closed registry:

rule = reviewedInterfaceRegistry[method]
authorizeProductUser(user, resource, action)
credential = credentialStore.get(rule.requiredAuthority, user)
callOpenApi(method, credential, validatedParams)

This is architecture pseudocode, not an Imou SDK. Logs should contain method, request ID, region, rule version, and redacted resource—not the credential.

Limits & pitfalls

The parameter name token does not identify token authority.
Do not infer rules for an entire module from one method.
Do not use administrator authority as an automatic fallback after a denied sub-account call.
Do not assume every device query accepts a sub-account token; verify the specific page.
Do not invent permission names or resource syntax.
Do not treat a sub-account token as safe to log, embed, or reuse across identities.
Do not place AppSecret or administrator tokens in browsers, mobile apps, desktop logs, or public repositories.
Do not treat Imou policies as a replacement for SaaS tenant authorization.
Do not claim universal token lifetime, revocation timing, or propagation behavior without live documentation.
Recheck all write methods and minimum permissions before publication and production release.

Review the register whenever a new endpoint is introduced. Security review should ask not only “is the token valid?” but “why is this authority required, which product identity requested it, and what resource has already been authorized?”

Start with the live Imou account docking documentation, then build a reviewed per-interface authority register before connecting user workflows.

Recovering a Silent Imou Callback: HTTP 200, Reachability and Re-subscription

Imou-OpenPlatform — Tue, 01 Sep 2026 07:06:51 +0000

Start recovery at the callback ingress, not at the device. Imou’s push guide requires the receiver to return HTTP 200 and warns that pushes can stop after the service fails to return the response multiple times. Verify public reachability and exact response codes, read the saved callback configuration, correct and re-enable it if needed, then generate a supported test event. The documentation publishes no retry count.

Why it matters

A silent callback can look like a device problem while every backend query remains healthy. It can also look like an Imou delivery problem when the request reached your edge but failed in parsing, a queue, or customer notification. Recovery becomes much faster when “delivery to ingress,” “acknowledgement,” “durable acceptance,” and “business processing” are separate observability stages.

The documented platform behavior is narrow but important: use an internet-accessible callback address, and return HTTP 200. The number, spacing, and backoff of failed attempts are not specified. A runbook that invents them creates false confidence and can delay escalation.

Approach / architecture

Use a thin callback path:

Imou Open Platform
  -> public HTTPS edge
  -> callback route
       -> bounded request checks
       -> durable enqueue
       -> HTTP 200
  -> asynchronous workers
       -> classify payload
       -> deduplicate
       -> retrieve optional media
       -> notify application users

This queue-first shape is application guidance, not a delivery guarantee from Imou. Its purpose is to remove slow or unreliable business work from the documented acknowledgement path.

Maintain four signals:

Signal	Question answered	Typical evidence
Edge requests	Did any request reach public infrastructure?	Load-balancer request record
HTTP 200	Did the callback satisfy the documented response?	Route status and response completion
Durable acceptance	Can the event survive worker failure?	Queue/store acknowledgement
Business completion	Did the user-facing action finish?	Worker and notification state

Seven recovery steps

Establish the last known good point. Compare the last ingress request, last returned 200, last persisted event, and last delivered notification. This prevents a downstream outage from being mislabeled as stopped pushes.
Probe from outside the private network. Verify DNS, TLS certificate chain, firewall, load balancer, route, and application process through the same public hostname configured with Imou. A browser test can hide redirects or authentication middleware, so inspect the actual status.
Check exact callback responses. The official guide says HTTP 200. Do not assume a redirect, 201, 202, 204, authentication challenge, gateway error, or timeout is equivalent. Review deployment changes that could add CSRF checks, login redirects, body limits, or synchronous processing.
Read platform configuration. Call getMessageCallback from a trusted backend. Compare returned status, callbackUrl, and callbackFlag with controlled configuration. Avoid relying on a screenshot or an old deployment variable.
Correct or re-subscribe deliberately. If configuration is wrong or delivery remains stopped after ingress health is restored, use setMessageCallback with an administrator accessToken, documented status, callback URL, flags, and applicable basePush. Record the authorized change; do not repeatedly toggle settings.
Generate a supported test event. Use a target device known to support an enabled event category. A quiet device, disabled detection, or unsupported event family does not test the transport.
Verify end to end. Confirm public receipt, HTTP 200, persistence, parsing, and final application action as separate checkpoints. Preserve UTC times, request identifiers, sanitized result codes, and the tested category for escalation.

APIs / SDKs

The event message push process is the canonical behavior source. It says events can be pushed to the developer’s backend callback, requires the callback service to return 200, and warns that the platform can stop pushing after multiple missing responses.

Use these documented interfaces:

getMessageCallback to inspect callback state, URL, and selected categories;
setMessageCallback to enable or disable subscription and set the internet-accessible callback;
the event format definition to validate the payload family used for testing; and
the event type definition to confirm documented event types.

Callback configuration is an administrator operation. Keep AppSecret and administrator accessToken in the backend. The public callback route should not expose those credentials.

Prevention and change control

Make callback health a deployment gate. Test the production hostname from an external probe, assert an exact 200 from the configured route, and verify a durable enqueue without invoking all business workers. Alert separately on non-200 responses, absence of ingress relative to known test activity, queue failures, unknown payload families, and notification errors.

Keep intended callback configuration in reviewed server-side configuration. Periodically compare it with getMessageCallback, especially after domain, certificate, proxy, or application migrations. Record who changed subscription state, which categories changed, how it was validated, and how to roll back.

Limits & pitfalls

Do not state a retry count, retry interval, backoff algorithm, or automatic restoration time. The cited page provides none.
Do not return a generic successful status other than 200 unless current documentation explicitly changes the requirement.
Do not acknowledge only after image downloads, database joins, or customer webhooks complete.
Do not assume no event means no delivery. Confirm device activity, enabled detection, category selection, and capability.
Do not repeatedly re-subscribe before fixing public reachability; that does not repair a broken ingress.
Do not let an unknown optional field make every callback fail. Preserve the bounded raw body and route parser failures for review.
Do not expose tokens, signed image URLs, device identifiers, or full payloads in support tickets.
Do not present queue design, idempotency, alert thresholds, or dead-letter behavior as Imou platform guarantees.
Recheck live callback documentation before publishing the runbook.

If recovery still fails after a healthy 200 path and verified configuration, prepare a factual escalation: developer account region, callback category, UTC test time, last successful time, sanitized configuration, request evidence from the edge, and redacted OpenAPI result IDs. Avoid unsupported conclusions about platform retry state.

Review the live Imou push process, then test your production callback as a small, observable ingress service before relying on downstream notifications.

Read Imou Event Payloads Without Assuming Every Alarm Has a Picture

Imou-OpenPlatform — Tue, 01 Sep 2026 07:06:17 +0000

Do not make images a required field in a universal Imou event schema. The current event-format page shows picUrlArray for specific face-detection and face-comparison payloads, while general alarms, online/offline events, accessories, statistics, heatmaps, and account/device lifecycle notifications use different shapes without that field. Route by documented msgType, preserve the raw body, and process media only when the applicable payload actually contains it.

Why it matters

An image-first parser fails in two directions. If it rejects an event without picUrlArray, valid status and alarm workflows disappear. If it assumes every URL is immediately displayable, the application may mishandle temporary references, encrypted media, or sensitive query strings. The safer abstraction is “event with optional evidence,” not “thumbnail with metadata.”

The event reference is closer to a workbook of payload families than one JSON schema. Even device and channel identifiers vary: examples can use did/cid, deviceId/channelId, msgDeviceId/msgChannelId, or accessory identifiers. Normalize only after family-specific parsing.

Approach / architecture

Build a two-layer event model:

Layer	Stored data	Purpose
Raw envelope	Bounded original body, receive time, request correlation	Replay, audit, future adapters
Normalized event	Internal event ID, family, device/channel references, type, occurred time, optional media references	Product workflow

The receiver should durably enqueue the raw event and return the required HTTP 200. A classifier then selects a versioned adapter from msgType and observed envelope. A separate media worker runs only when that adapter identifies a documented, populated image field. Business notifications should remain useful when media is absent.

What the current examples show

Documented family	Representative field	`picUrlArray` shown?	Product treatment
General device alarm	`did`, `cid`, `msgType`	No	Accept without thumbnail
Device online/offline	`did`, `cid`, `online`/`offline`	No	Status transition
Gateway accessory	`deviceId`, `accessoriesId`	No	Family-specific `desc`
Face detection	`aiFaceDetect`	Yes	Conditional image job
Face comparison	`aiAFaceCompa`, `aiSFaceCompa`	Yes	Parse exact comparison shape
Traffic statistics	`detail`	No	Structured count data
Heatmap	`desc.heatData`	No	Structured heat data
Sharing/binding/authorization	lifecycle `msgType` values	No	Identity or inventory reconciliation

“No” means the cited example does not define that image array. It is not a promise that no future or device-specific message could add optional fields. The current page and target event type must be checked during implementation.

Seven implementation steps

Subscribe deliberately. Configure setMessageCallback with only the documented callback categories needed by the product. A selected category does not guarantee all devices generate every event.
Acknowledge at ingress. Validate basic request constraints, write to durable storage or a queue, and return HTTP 200. Do not block acknowledgement on image download, customer notification, or a database join.
Preserve the original body. Keep a bounded raw representation under access controls. This lets you repair an adapter without inventing what the sender provided.
Classify before validation. Identify the documented family and msgType, then apply that family’s required fields. Do not require did and deviceId simultaneously.
Create optional media work. Test that the exact documented field exists, is the expected type, and has usable values. If not, continue the image-free workflow and show a deliberate “image unavailable” state.
Handle media securely. Retrieve applicable references promptly according to the live page, redact URL query material in logs, and use the official image-decryption component where required. Keep decryption material outside public clients and repositories.
Reconcile and observe. Track unknown msgType, malformed family payloads, image retrieval outcomes, and downstream notifications separately. Unknown optional fields should not poison callback acknowledgement.

APIs / SDKs

The event message format definition is canonical for the payload examples discussed here. It currently documents picUrlArray in face-detection and face-comparison examples. Those examples also contain a note about image-data storage time; treat that note only in the context where it appears and require publication-day review before quoting any duration.

Other useful sources are:

the event push process for callback delivery and HTTP 200 acknowledgement;
setMessageCallback for subscription state and categories;
the event type definition for documented msgType values;
getAlarmMessage for a separate query response that may contain picurlArray and thumbUrl; and
the resource download page for official image-decryption resources.

Notice the casing difference: face callbacks show picUrlArray; getAlarmMessage documents picurlArray. Do not lower-case or rename fields before selecting the source-specific adapter.

Contract design for downstream teams

Expose a normalized media collection as optional, and record provenance such as callback field, queried alarm record, or another documented source. Consumers should render event type, time, device, and channel without media. A thumbnail can enhance a card but must not determine whether the event exists.

Version the normalized contract independently from raw Imou payloads. When documentation or observed supported payloads evolve, add an adapter and fixture. Avoid changing historical raw events or silently interpreting an absent field as an empty picture.

Limits & pitfalls

No current source cited here promises that every alarm includes a picture.
A missing image is not proof of callback failure; it may be valid for the message family.
A push payload and an alarm-query response are different contracts, even if both concern one incident.
Do not promise one-to-one reconciliation between every callback and queried media unless your tested workflow proves it.
Do not log full image URLs, tokens, device credentials, or unredacted payloads.
Do not assume an image-like URL returns a browser-ready JPEG; follow official decryption guidance.
Do not infer support for face events, statistics, or heatmaps across all devices.
Do not quote image availability or retention timing without checking the live source on publication day.
Keep parser retries and dead-letter policy as your own operational design, not an Imou guarantee.

Use fixtures copied from sanitized, authorized test traffic and from current documentation. For each adapter, test the expected shape, missing optional media, additional unknown fields, malformed media arrays, and an image worker failure. The callback receiver should still satisfy its acknowledgement path.

Use the live Imou event format reference to build family-specific fixtures, then validate image handling with the exact devices and services in your product.

SDK-Assisted Binding: When HTTP bindDevice Is Not Enough

Imou-OpenPlatform — Tue, 01 Sep 2026 07:05:46 +0000

HTTP bindDevice is not a universal onboarding shortcut. Imou’s mobile application guide says some newer devices, and older devices upgraded to newer software, may require client OpenSDK participation to complete binding. Treat onboarding as a version-dependent state machine: discover the device state, complete required local configuration or initialization through the current SDK demo, use backend binding where applicable, and verify the final account association.

Why it matters

A failed binding request is often handled as a networking problem: retry the request, rotate the token, or ask the user to scan the label again. That response misses a structural issue. Network configuration, device initialization, platform reachability, verification, and account binding are separate states. A correct HTTP request cannot replace a required local SDK stage.

This is also a security boundary. The backend has application credentials and can make signed OpenAPI calls. The mobile client can interact with a device on the local network and follow SDK workflows. Moving AppSecret or an administrator token into the app to “simplify” binding weakens the system without making an incompatible flow compatible.

Approach / architecture

Use a resumable onboarding coordinator rather than one “Add camera” request:

State	Owner	Evidence to retain	Never retain
Device identified	Client/backend	Redacted serial reference, scan result	Public full labels
Access mode discovered	Client	Supported configuration path	Guessed model rules
Network configured	Client OpenSDK	Completion state and sanitized error	Wi-Fi credentials in analytics
Initialized if required	Client OpenSDK	SDK stage and version	Device password in logs
Binding branch selected	Coordinator	Why SDK or HTTP path was chosen	A universal “new device” flag
Account bound	Backend/platform	Account-device relationship	Administrator token in client
Inventory verified	Backend	Device/channel record	Unverified success from UI alone

The official mobile application guide is explicit that binding processes vary by device version and directs developers to the client SDK demo. Therefore, code should model branches and durable progress, not hard-code one imagined SDK method.

Six steps for an SDK-assisted flow

Capture the first failure accurately. Save the OpenAPI method, response id, result.code, result.msg, account region, application version, and SDK version. Redact tokens and verification material. Do not immediately classify the cause as a security upgrade.
Inspect the unbound-device state. Use the documented device query path, such as unBindDeviceInfo, to learn what the platform reports about support, status, binding state, configuration mode, and capabilities. Treat returned data as evidence for this device only.
Complete local prerequisites. Follow the current Android or iOS OpenSDK demo for the detected configuration path. Network configuration and initialization may require direct client-device interaction. Keep sensitive inputs in the narrowest possible scope and clear them after use.
Choose the binding branch from documented state. The mobile guide says SDK assistance may be needed; it does not say every new device rejects HTTP binding. If the current SDK workflow completes the relevant binding stage, record that result. If it hands off to backend HTTP binding, continue there.
Call bindDevice only with documented inputs. The live bindDevice page requires an administrator accessToken. Its code meaning depends on device capability and state; encryptCode is an optional documented alternative. Do not copy a credential rule from another model.
Verify and reconcile. Query the intended account’s device inventory, persist device and channel identifiers, and mark onboarding complete only after the backend observes the association. Make repeated client submissions idempotent in your own coordinator.

APIs / SDKs

The central source is the application development guide. It assigns network configuration, initialization, audio/video playback, and picture decryption to client SDK workflows, while recommending backend HTTP APIs for account and device binding/unbinding, management, operations, cloud storage, and alarms. Its binding section adds the important exception: security-upgraded devices may need the client SDK in the binding process.

Supporting interfaces include:

unBindDeviceInfo for pre-binding device information;
bindDevice for administrator-authorized HTTP binding where applicable;
device query interfaces for confirming the post-binding inventory; and
current Android/iOS OpenSDK packages and demos for local configuration, initialization, and binding branches.

Use the demo as executable guidance for the installed SDK version. Pseudocode should remain intentionally generic:

state = backend.inspectUnboundDevice(deviceRef)
clientOutcome = client.followCurrentOpenSdkDemo(state)
if clientOutcome.requiresBackendBind:
    backend.bindDevice(clientOutcome.secureCredentialReference)
backend.verifyAccountInventory(deviceRef)

This describes responsibility flow, not real OpenSDK method names.

Operational testing

Build a test matrix around combinations you actually support: factory-state and previously initialized devices; supported provisioning modes; online and offline starts; app termination between stages; device already bound elsewhere; incorrect verification input; and a successful resume after interruption. Record the software and SDK versions for every result.

The objective is not to derive a universal model table from a few samples. It is to prove that your coordinator can identify the next safe action, avoid replaying completed sensitive stages, and give support staff enough sanitized evidence to distinguish local configuration, initialization, authorization, and account-binding failures.

Limits & pitfalls

“May need SDK-assisted binding” does not mean “all new devices must use SDK binding.”
An HTTP error alone does not prove a security-version mismatch. Check region, signature, token, parameters, existing binding, reachability, and device state.
Do not retry indefinitely. Imou’s guide does not publish a binding retry schedule; define application policy from your own tests.
Do not put AppSecret or administrator accessToken in a mobile app, browser bundle, crash report, or support screenshot.
Do not log Wi-Fi passwords, device passwords, security codes, encryptCode, or complete signed requests.
Do not invent SDK calls from architecture diagrams. Use the current package documentation and demo.
Do not promise support for every device, firmware, configuration mode, or region.
Revalidate the full flow whenever the SDK, mobile OS, device software, or backend interface changes.

A useful support bundle contains the last completed state, current SDK and app versions, account region, sanitized platform response, device-reported model/software information where available, and whether the physical device was bound before. It excludes all reusable credentials.

Review the live Imou mobile application guide and current OpenSDK demo, then prove each supported binding branch with the devices you plan to deploy.

What Developers Can Build with Imou Open Platform Besides Live Video

Imou-OpenPlatform — Tue, 01 Sep 2026 07:05:11 +0000

Beyond live video, Imou Open Platform exposes building blocks for device access and management, event callbacks, recorded-video playback, cloud video or snapshot storage, client applications, Home Assistant integration, and SaaS-oriented fleet and permission workflows. Treat these as separate capabilities: the combination available to a product depends on the target device, firmware, account region, client surface, and subscribed services.

Why it matters

“Show a camera stream” is an easy prototype goal, but it is rarely a complete product requirement. A deployed application must also bring devices online, associate them with the right account, decide which user may control which channel, receive events, retain useful evidence, and remove access when a user leaves. Starting from the stream tends to push these decisions into ad hoc code.

The Imou homepage is more useful as a capability map than as a list of promises. It groups the platform into Device Access, Video Security, Value-Added Services, App Development, Integrating Home Assistant, and SaaS Application. Those groups suggest workstreams, but each method and field still has to be verified in the current documentation.

Approach / architecture

Model the product as a set of independently testable planes:

Plane	Product responsibility	Imou building blocks	Boundary to verify
Onboarding	Put an intended device under an intended account	Network configuration, initialization, binding	Device generation and supported flow
Inventory	Know devices, channels, state, and capabilities	Device query and management APIs	Returned capabilities, not model assumptions
Authorization	Limit who can reach each resource	Administrator and sub-account model, policies	Per-interface token and permission rules
Events	Turn device activity into application workflow	Message callback and event formats	Selected categories and payload family
Evidence	Preserve useful context	Cloud snapshot or cloud video storage	Service entitlement and media availability
Client experience	Preview, playback, talk, or device interaction	Mobile/PC OpenSDK and web components	Client-specific documented functions
Operations	Support fleets and business users	Backend APIs and SaaS-oriented management	Your tenant, audit, and offboarding controls

The trusted backend should own AppSecret, signed OpenAPI requests, administrator credentials, tenant authorization, and callback ingestion. Client SDKs should own only the local or media jobs documented for that client. A browser, mobile app, or desktop client is not a substitute for the backend control plane.

This split is architecture guidance. The homepage describes product areas; it does not prescribe your database, queue, identity provider, or deployment model.

A six-step capability discovery process

Write one operational journey. Replace “integrate cameras” with a verifiable flow such as “an installer adds a supported device, an operator receives an event, and an authorized reviewer opens the available evidence.”
Choose the device-access path. The homepage presents Imou product access, OEM finished products, zero-code development, and network modules. Confirm the commercial and technical route before assuming all hardware enters through the same flow.
Inventory device and channel capabilities. Query the target device instead of publishing a universal feature list. Preview, playback, talk, PTZ, event types, and storage can vary. Preserve device IDs and channel IDs as distinct resources.
Design identities before controls. Keep administrative jobs in a restricted control plane. Where an interface accepts a sub-account token, grant only the documented resource and permission needed by that application user. Your own tenant and role check must run first.
Add events and evidence separately. Configure the callback categories the product needs, return the documented HTTP 200 from a durable ingress path, and parse payloads by msgType. Then decide whether a snapshot, video, or no media is appropriate. An event does not guarantee an image.
Select and test the client surface. Evaluate mobile OpenSDK, PC OpenSDK, browser components, cloud live, or Home Assistant against the exact workflow. Test normal operation, offline devices, revoked access, missing media, and offboarding before expanding the fleet.

APIs / SDKs

The Imou Open Platform homepage is the canonical source for the capability groups in this article. For implementation, move from that map to the current documentation:

The mobile application guide separates SDK-oriented work such as network configuration, initialization, playback, and picture decryption from backend HTTP work such as account and device management, storage management, and alarm management.
The HTTP development specification defines regional API endpoints, request envelopes, and signing.
The event push guide defines callback setup and the HTTP 200 acknowledgement requirement.
The event format reference shows that different message families have different envelopes and media fields.
The PC application guide describes a desktop OpenSDK media path backed by server-side token and device-list work.

These references establish responsibilities, not universal compatibility. Verify each desired method on its own page and with the actual deployment.

A practical product map

A home-security application may combine binding, device inventory, event callbacks, playback, and optional storage. A retail operations product may emphasize fleet grouping, permissions, event triage, and retained evidence. A smart-home integration may expose selected entities and operations while leaving account administration in the backend. A desktop monitoring station may use PC OpenSDK for media interaction while the backend handles accounts and devices.

The important pattern is composition. “Imou supports cloud storage” does not prove that a given channel has an active storage service. “App Development” does not mean one SDK supports every client environment. “AIoT” does not establish a public AI endpoint or a result for every alarm. Record each dependency beside the feature that needs it.

Limits & pitfalls

Do not turn homepage examples into a model-by-model support matrix.
Do not expose AppSecret, administrator tokens, sub-account tokens, live addresses, or signed media URLs in public code or logs.
Do not assume every callback carries an image or every device emits every documented event.
Do not treat platform permissions as your product’s tenant authorization. Both boundaries are required.
Do not infer pricing, SLA, data residency, storage duration, or entitlement from a product label.
Do not invent AI endpoints or promise AI output for unsupported devices or services.
Do not select a regional API hostname from the end user’s location; use the data center assigned to the developer account.
Recheck live documentation before implementation and publication because methods, packages, and client components can evolve.

Maintain a capability register for the pilot: desired user outcome, official source, device/channel tested, required service, client surface, observed result, and fallback state. That register turns a broad platform map into evidence a product team can safely ship.

Explore the current capability map at Imou Open Platform, then validate one complete device-to-user journey with the target devices and services.

Bridge Imou HTTP Callbacks When a Home Assistant Integration Polls

Imou-OpenPlatform — Tue, 01 Sep 2026 07:04:38 +0000

If your Home Assistant Imou path talks to the cloud API on a poll interval, it will not see alarms at callback latency. For nearer-real-time events, subscribe with Open Platform setMessageCallback to a backend you control, return HTTP 200, then forward a sanitized event into Home Assistant through a mechanism you own (webhook automation, MQTT, or a custom component). That bridge is application architecture, not a Core integration feature and not an Imou delivery SLA. API and playback traffic still consume the developer application quota.

Why it matters

Users expect motion to fire lights immediately. A polling integration can only be as fresh as its scan interval and remaining quota. Explaining that honestly prevents duplicate “broken sensor” issues. Building a bridge is optional engineering; it must not be marketed as a hidden official HA option without verifying repositories on publish day.

Approach / architecture

Imou device
  -> Open Platform callback
  -> your public HTTPS receiver (200 then queue)
  -> map deviceId/channel to HA entity
  -> HA webhook / MQTT / event bus

Path	Freshness	Notes
HA cloud poll	Interval-bound	Uses App ID quota for listed API calls
Open Platform callback + bridge	Callback-bound, minus your queue delay	You operate the receiver
Local-only speculation	Not claimed here	Do not invent undocumented LAN event APIs

Name integrations carefully. Home Assistant Core imou and any separately maintained HACS component can differ. Verify the Core page and current repository ownership before you write “official.”

Six implementation steps

Confirm how your installed integration actually refreshes. Read its docs and code path; do not assume webhooks.
Stand up setMessageCallback with documented flags and a public URL. Administrator token stays on the bridge backend.
Acknowledge 200 first. Parse, enqueue, then map to HA.
Map identifiers explicitly. Imou deviceId/channelId to HA entity_id. Keep a table you control.
Sanitize payloads. Do not dump encrypted images or personal data into HA history by default.
Watch quota. Extra live views and API calls in HA still bill against the same App ID resources documented for that account.

APIs / SDKs

No prices, lead forms, or unverified “official” claims.

Limits & pitfalls

The bridge is not a guarantee of zero missed events; combine with query if you need reconciliation (guidance only).
Do not put appSecret in configuration.yaml.
Recheck HA docs, callback flags, and quota notes on publication day.

Operating the bridge without turning HA into a SaaS funnel

Keep the receiver, mapper, and Home Assistant instance in systems you administer. Rate-limit forwards so a noisy camera cannot flood HA’s recorder. Drop or summarize events you do not need.

If Core already creates binary sensors from poll, decide whether the bridge duplicates them. Duplicate entities confuse automations. A dedicated event stream with device_id in data may be cleaner than flipping a polled sensor.

Quota: extra get* calls you add “to be sure” can exhaust the same App ID used by the integration. Measure your own API volume.

Security: the callback URL is an ingress surface. Restrict source networks if you can operate that; still return 200 only after basic validation so you do not teach the platform that your URL is dead.

This pattern is for integrators who already run a backend. It is not a community how-to for bypassing Home Assistant’s architecture, and it is not a claim that Imou maintains a webhook integration inside Core. Recheck haDev.html and the Core integration page on the day you publish.

Read the Imou HA guide and the callback interface, then decide whether polling is enough or whether you will operate a callback bridge yourself.

A Backend Checklist for Imou Signatures: Time, Nonce, id and SN1005

Imou-OpenPlatform — Tue, 01 Sep 2026 07:03:56 +0000

Stop most signature failures in code by synchronizing UTC time, generating a 32-bit nonce that never repeats inside the documented five-minute window, sending a unique non-empty request id, pairing appId with appSecret, posting to the assigned regional host, and matching the live HMAC procedure including the official test vector. Nonce reuse in that window currently returns SN1005. Do not restate a forked algorithm in a wiki; implement the development specification page.

Why it matters

Production incidents often mix four bugs: clock drift on Kubernetes nodes, a shared nonce in a retry helper, an empty id, and the wrong data center. A checklist that runs in CI and in the HTTP client prevents “it worked on my laptop.”

Approach / architecture

Keep a SignAndSend function that always allocates a fresh envelope:

for each attempt:
  time = utc_epoch_seconds()
  nonce = unique_32bit()
  id = unique_nonempty()
  sign = official_algorithm(appId, secret, time, nonce, params)
  POST assigned_host /openapi/method

Retries that copy system fields cause SN1005. Architecture recommendation: retry at this envelope boundary, and keep a separate internal correlation id for logs.

Seven implementation steps

NTP or equivalent on every worker that signs. Stay comfortably inside the five-minute window; do not skim the edge.
Centralize nonce generation with a uniqueness store or cryptographically strong RNG plus a short-lived seen-set shared across replicas.
Always set id. Empty or duplicate ids fail independently of HMAC.
Lock algorithm to the live page. Use the official Java sample and fixed expected value as a unit test. Never commit the sample secret as production config.
Separate host selection from signing. Wrong openapi-sg versus openapi-fk versus openapi-or is not a HMAC bug.
Log fingerprints only: time, nonce hash, id, appId suffix, region, result code.
On SN1005, inspect retries and cloned HTTP clients before rotating appSecret.

APIs / SDKs

HTTP development specification

Do not duplicate the byte-level sign string in this article; it drifts. The live page is the contract.

Limits & pitfalls

Milliseconds versus seconds for time is a common defect.
Multi-thread nonce collisions look like random production-only failures.
Do not claim all auth errors are SN1005.
Recheck the five-minute rule, nonce width, and test vector on publication day.

Test harness and multi-worker reality

Unit-test the signer with the official vector on every build. Integration-test against the assigned regional host in staging with a dedicated appId. Never point CI at production secrets.

In Kubernetes, clock skew between nodes is enough to flake signatures near the five-minute boundary. Use an NTP sidecar or node-level time sync, and fail health checks if skew exceeds a conservative threshold you choose—without claiming that threshold is Imou’s.

Nonce uniqueness across replicas needs a shared store or a generator with collision resistance plus TTL keys. A local HashSet is not enough for two pods.

When reproducing a customer failure, ask for request id, UTC time, region, and result code. Re-running their exact nonce is the wrong lesson; you want to know whether they reused it.

Do not wrap the official algorithm in a “simplified” library that omits id or changes encoding. Language ports should be checked against the same vector.

Put the official test vector in CI, then ship a signer that mints a new time, nonce, and id on every attempt using the development specification from Imou Open Platform.

DEV Community: Imou-OpenPlatform

Imou Open Platform Production Checklist: Devices, Events, Permissions and Storage

Why it matters

Approach / architecture

Seven production gates

APIs / SDKs

Required test evidence

Release and rollback

Limits & pitfalls

Go/no-go record

Operate Imou Live Addresses Using Status, Plans and Insufficient-Traffic Signals

Why it matters

Approach / architecture

Exact current status vocabularies

Address-level liveStatus from liveList

Stream-level status from queryLiveStatus

Seven operational steps

APIs / SDKs

Observability and incident records

Limits & pitfalls

Desktop Private Protocol vs Browser Integration on Imou Open Platform

Why it matters

Approach / architecture

Six decision and implementation steps

APIs / SDKs

A client-boundary blueprint

Operational questions before choosing PC

Limits & pitfalls

Configure Imou Regional Endpoints: Singapore, Frankfurt and Oregon

Why it matters

Approach / architecture

Current documented mapping

Six configuration steps

APIs / SDKs

Troubleshooting endpoint mismatches

Limits & pitfalls

Retention Design for Imou Cloud Snapshot vs Cloud Video Storage

Why it matters

Approach / architecture

Six design and implementation steps

APIs / SDKs

Mixed retention can be intentional

Retention review questions

Limits & pitfalls

Classify Imou HTTP Interfaces by Administrator vs Sub-Account Token

Why it matters

Approach / architecture

A documentation-bounded classification

Seven implementation steps

APIs / SDKs

Credential-selection pattern

Limits & pitfalls

Recovering a Silent Imou Callback: HTTP 200, Reachability and Re-subscription

Why it matters

Approach / architecture

Seven recovery steps

APIs / SDKs

Prevention and change control

Limits & pitfalls

Read Imou Event Payloads Without Assuming Every Alarm Has a Picture

Why it matters

Approach / architecture

What the current examples show

Seven implementation steps

APIs / SDKs

Contract design for downstream teams

Limits & pitfalls

SDK-Assisted Binding: When HTTP bindDevice Is Not Enough

Why it matters

Approach / architecture

Six steps for an SDK-assisted flow

APIs / SDKs

Operational testing

Limits & pitfalls

What Developers Can Build with Imou Open Platform Besides Live Video

Why it matters

Approach / architecture

A six-step capability discovery process

APIs / SDKs

A practical product map

Address-level `liveStatus` from `liveList`

Stream-level `status` from `queryLiveStatus`