Activating Imou Cloud Storage via API: strategyId, Call Quotas and unUsedCloudList

Activate Imou cloud storage from a trusted backend with openCloudRecord. The required parameters are an administrator accessToken, deviceId, channelId, and strategyId; deviceCloudId is optional when activating an unused cloud service returned by unUsedCloudList. One call activates one device channel. Before using call balance, query queryCloudRecordCallNum; a successful activation through that path reduces the remaining count for the specified storage strategy by one.

Why it matters

Cloud storage activation is a lifecycle operation, not a player-side toggle. It selects a package strategy and applies it to a specific device channel under administrator authority. A backend must therefore check the target, choose the entitlement path, serialize the operation safely, and verify the resulting service state.

The live documentation describes two inputs to activation:

1. remaining activation calls for a strategyId, queried with queryCloudRecordCallNum; or
2. unused cloud-storage services under the developer account, listed by unUsedCloudList, whose deviceCloudId can be supplied to openCloudRecord.

Do not treat those as an unlimited free trial or a public price offer. They are documented API states for the developer account.

Activation architecture

Admin / approved backend workflow
                |
                v
Validate tenant + device + channel
                |
                v
Choose entitlement path
  A. queryCloudRecordCallNum(strategyId)
  B. unUsedCloudList -> deviceCloudId
                |
                v
openCloudRecord(deviceId, channelId, strategyId, [deviceCloudId])
                |
                v
Verify with deviceCloudList / application ledger

Component	Responsibility
Product backend	Authorization, target validation, orchestration, audit record
Administrator token	Authorizes activation APIs; stays on the backend
strategyId	Identifies the cloud-storage package strategy
deviceCloudId	Optional unique cloud-service ID from unUsedCloudList
Device and channel	Exact activation target; one channel per call
Imou cloud service	Processes activation and exposes service state through documented APIs

Six implementation steps

1. Validate the target

Resolve the exact deviceId and channelId from your inventory. Check that the requesting tenant or administrator is allowed to activate a service for that channel. One activation call covers one channel, so a multi-channel device requires separate, reviewed operations.

2. Select a documented strategyId

The strategyId is the cloud-storage package ID. Obtain it from the applicable package information for the account; do not hard-code a sample value from documentation as a universal production strategy.

3. Check the entitlement source

For call-balance activation, call:

{
  "params": {
    "token": "ADMIN_ACCESS_TOKEN",
    "strategyId": 10003
  }
}

queryCloudRecordCallNum returns callNum, the remaining number of calls to openCloudRecord for the queried strategy. Proceed through this path only when the returned number is greater than zero, as described on the activation page.

Alternatively, call unUsedCloudList. Its remarks say it lists cloud services returned to the developer account after device unbinding; for remaining activation counts, use queryCloudRecordCallNum. An unused item includes fields such as deviceCloudId and strategyId.

4. Call openCloudRecord

The required activation payload is:

{
  "params": {
    "token": "ADMIN_ACCESS_TOKEN",
    "deviceId": "DEVICE123",
    "channelId": "0",
    "strategyId": "SELECTED_STRATEGY_ID"
  }
}

When using a specific unused service from the developer account, include its returned ID:

{
  "params": {
    "token": "ADMIN_ACCESS_TOKEN",
    "deviceId": "DEVICE123",
    "channelId": "0",
    "strategyId": "SELECTED_STRATEGY_ID",
    "deviceCloudId": "UNUSED_CLOUD_SERVICE_ID"
  }
}

These snippets show params; the complete OpenAPI request also needs the normal signed request envelope.

5. Record the result

The openCloudRecord page documents no returned data body beyond the operation result. Store the request target, selected strategy, entitlement path, request ID, response code, and timestamp in your own activation ledger.

6. Verify service state

Use deviceCloudList to query cloud-storage services under the device channel. The interface returns strategy and status information for that target. Verification is safer than assuming a UI should display storage merely because an orchestration job attempted the call.

The two entitlement paths

Path	Pre-check	openCloudRecord input	Documented effect
Remaining call balance	queryCloudRecordCallNum(strategyId) returns callNum > 0	Required fields	Remaining count for the specified storage decreases by one after activation
Unused service	unUsedCloudList returns an available item	Required fields plus optional deviceCloudId from the item	Applies that unused service to the device channel

This table describes interface behavior, not billing advice. Confirm commercial eligibility and package availability through the appropriate Imou account or business channel.

Orchestration guidance

The docs define request fields and account state; your backend should add operational controls:

• use a unique internal activation operation per device/channel and intended package;
• prevent two workers from activating the same target concurrently;
• re-read current service state before retrying an ambiguous timeout;
• retain the Imou request id and response for support investigation; and
• reconcile requested activations against deviceCloudList.

These are architecture recommendations. They are not claims that openCloudRecord offers an idempotency key or a particular retry guarantee.

Limits and pitfalls

Activating multiple channels in one call

The documentation says each call enables cloud storage for one channel of one device. Iterate through reviewed channel targets; do not send an undocumented channel array.

Omitting required fields

token, deviceId, channelId, and strategyId are all required. deviceCloudId is optional and is obtained from unUsedCloudList when activating a cloud service under the developer account.

Using a sub-account token

The openCloudRecord parameter table requires an administrator accessToken. Keep it on the trusted backend.

Copying sample strategy IDs

Documentation samples illustrate shape, not universal account entitlement. Resolve the strategy applicable to the current account and service.

Calling without balance or an unused service

Follow the documented preconditions: positive callNum for the call-balance route, or an available item returned by unUsedCloudList.

Confusing activation with recording retrieval

Activation manages service lifecycle. APIs such as getCloudRecords retrieve records after the service and device have produced them. A successful activation is not a promise that historical or immediate clips exist.

Publishing inferred prices

The API pages do not establish a public global price, discount, or universal trial. Keep commercial claims outside the technical implementation unless a current approved source supports them.

Backend checklist

• [ ] Target deviceId and channelId belong to the approved tenant.
• [ ] strategyId comes from applicable package information.
• [ ] Entitlement path is either positive callNum or an available unused service.
• [ ] Each operation contains exactly one device channel.
• [ ] Administrator token and AppSecret remain server-side.
• [ ] Result and request ID are recorded.
• [ ] deviceCloudList verifies post-operation state.

Treat a successful operation result and a verified service-state query as separate evidence. Preserve both in the activation ledger so later support work does not rely on an inferred entitlement state.

Register at Imou Open Platform to test cloud-storage lifecycle APIs with your assigned account packages before automating production activation.

Official sources

• openCloudRecord
• queryCloudRecordCallNum
• unUsedCloudList
• deviceCloudList
• Cloud storage service interface list