Retention Design for Imou Cloud Snapshot vs Cloud Video Storage

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

1. 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.”

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.