Use liveList to inventory live addresses created under the developer account, queryLiveStatus to inspect stream-level health by liveToken, and getLiveStreamInfo to resolve addresses for a device and channel. Store job schedule fields and liveStatus exactly as returned. The current liveList documentation defines status 3 as insufficient traffic; treat it as an operational signal, not a pricing conclusion.
Why an address audit matters
Creating a stream is only the beginning. Teams also need to know which address belongs to which device channel, whether a plan is enabled, which stream variants exist, and whether a failure is address-wide or stream-specific. A periodic inventory closes that operational gap without turning this article into another basic live-stream selection guide.
Documented API roles
liveList returns a paged account-level list and includes liveToken, liveStatus, liveType, optional device identity, channel, stream entries, and job. queryLiveStatus accepts an administrator token and liveToken, then returns stream-level streamId and status. getLiveStreamInfo accepts administrator token, deviceId, and channelId, and returns created HLS address information, status, and live token. A prior bindDeviceLive creation is required for the list or device-channel query to find an address.
Do not merge two status vocabularies
The liveStatus on liveList is an address-level field: 1 open, 2 pause, and 3 insufficient traffic in the current page. The status returned per stream by queryLiveStatus uses a different documented vocabulary, including 0 live, 1 live with abnormal cover, 2 abnormal video source, 3 abnormal stream conversion, 4 abnormal cloud-storage access, and 10 paused. Preserve both names and never translate one into the other.
Recommended inventory model
Architecture recommendation: key the ledger by liveToken, with secondary lookup by device, channel, protocol, and stream ID. Save the last observation time, source method, address-level state, stream-level state, and schedule snapshot. Encrypt or restrict address values and expose only redacted forms to normal operators. This schema is an operator design, not an Imou-prescribed database.
Audit steps
- Call
liveListwith a documentedqueryRangeand continue until the inventory is covered. 2. Normalize each returned live entry without changing status values. 3. For important or anomalous entries, callqueryLiveStatuswith itsliveToken. 4. When starting from an asset record, callgetLiveStreamInfowith device and channel. 5. Compare the returnedjobsnapshot with the intended schedule. 6. Route discrepancies to an operator; do not automatically recreate addresses before confirming ownership and demand.
Scheduling without assumptions
The job object documented by liveList contains schedule status, period, begin time, and end time. Treat these values as the platform snapshot. Changes belong to the documented plan methods such as modifyLivePlanStatus, modifyLivePlan, or batchModifyLivePlan; this audit should detect drift before deciding whether to write. Do not infer timezone, recurrence semantics, or billing behavior beyond the live method pages.
Pitfalls
Do not log full HLS addresses, assume list order is stable, equate count with healthy streams, or interpret every nonzero stream status as the same incident. Do not call status 3 a universal account balance error: the verified claim is only that current liveList documentation labels liveStatus 3 as insufficient traffic. Escalate with the method, request ID, region, and redacted token.
Soft next step
Register at Imou Open Platform and validate this audit against a test address. The platform supplies cloud-video APIs and SDKs; your backend remains responsible for authorization, address hygiene, inventory retention, and operator workflow.
Verification discipline
Treat the linked live documentation as the boundary of the claim. Capture the page and review date in the release ticket, and recheck method names, fields, permissions, regions, and status values before publication. Console behavior and repositories can change after this draft. If the live source disagrees with this article, update the article rather than preserving an outdated assertion.
Secret handling
Keep App Secret values and administrator access tokens on a trusted backend. Do not place them in Home Assistant YAML shared publicly, browser bundles, mobile logs, screenshots, sample repositories, or support tickets. Redact device identifiers and live addresses in diagnostics. A live URL is operational data and should be distributed only through the authorization boundary designed by the application owner.
Capability and service boundaries
A documented platform method does not prove that every device, channel, account, or subscribed service supports the same outcome. Test with the actual account region and target device family. Present missing controls as a capability or service question first, then gather diagnostics, instead of promising universal behavior or inventing a model matrix.
Observability
Record the request ID, method, region, result code, and a redacted resource identifier for backend calls. Add timestamps around each stage so operators can distinguish local validation, platform rejection, device availability, and downstream delivery. Logs must never contain App Secret values, full administrator tokens, reusable live URLs, or unredacted callback payloads.
Rollout practice
Start with one test application, one account region, one device, and one channel. Validate the happy path and an intentional failure before expanding. A staged rollout makes region mistakes, quota pressure, unsupported capabilities, and stale credentials visible while the affected inventory is still small.
Architecture status
Unless a sentence is explicitly attributed to Imou or Home Assistant documentation, workflow choices in this article are recommendations, not platform guarantees. Queue design, caching, reconciliation, alert thresholds, and retry policy belong to the application operator. They should be tuned from measured behavior without being presented as an Imou SLA.
Change control
Put region, callback, credential, schedule, and integration changes through review. Record the old value, intended value, operator, validation request, and rollback condition. This is especially important where a seemingly small configuration edit can change cloud traffic or make an entire device group unavailable. Review current documentation again when applying a saved runbook.
Test evidence
A useful community or production report states what was tested without exposing private material: Home Assistant or application version, integration path, account region, method, device capability category, UTC time, and redacted result. Separate observed evidence from interpretation. That makes later maintenance possible even when repository releases or platform documentation have moved.
Archive each completed audit with its scope and timestamp; otherwise two correct inventories from different moments can be mistaken for one contradictory result.
Official sources
Live-source review date: 2026-08-31. Recheck before publication.
Top comments (0)