Imou Permission Inheritance and the 10-Resource addPolicy Limit

In Imou sub-account policies, a cam: channel belongs to its parent dev: device, so a permission granted on the device can pass to that device’s child channels. Use addPolicy with an administrator accessToken, the sub-account openid, and a Policy. The live addPolicy page limits one request to a maximum of 10 devices or channels and says the statement or resource array cannot exceed 10.

Why it matters

Inheritance saves repetitive policy entries, but it can also broaden access. Request limits create a second concern: a fleet cannot be authorized in one unbounded payload. If you misunderstand either rule, you may expose more channels than intended or build a provisioning job that fails as the fleet grows.

The safest implementation separates two questions:

1. Scope: should the grant cover a whole device or selected channels?
2. Transport: how should the intended grants be divided into documented addPolicy requests?

Do not solve the second question by widening the first.

Resource and inheritance model

Resource	Shape	Meaning	Inheritance consequence
Device	dev:DEVICE123	The device resource	A permission on it can pass to child cam: resources
Channel	cam:DEVICE123:0	One channel belonging to the device	Scope is explicit to that channel

The official sub-account description gives a concrete example: if Real is authorized on dev:544229080, the child cam:544229080:1 has Real by default. That is the documented direction to rely on: device to child channel. It is not a reason to infer that a channel grant expands to its parent or sibling channels.

For a single-channel user, write the channel resource. For a role that genuinely needs all child channels of a device, a device resource can express that intent. Your application should make that choice before it creates a Policy.

What the 10-resource limit says

The current addPolicy documentation states:

• a single request can authorize a maximum of 10 devices or channels; and
• the length of the statement array or the resource array in the documented input example cannot exceed 10.

Keep each array at 10 or fewer, and keep the request’s total authorized devices or channels at 10 or fewer. Do not interpret “10 resources” as permission to send an arbitrary number of statements with ten resources each. A conservative request builder validates the statement length, every resource-array length, and the total resource references.

Implementation architecture

Product roles and assignments
          |
          v
Desired-grant builder
  {openid, permission, resource}
          |
          v
Scope review
  dev: whole-device intent?
  cam: selected-channel intent?
          |
          v
Batch planner (<=10 statements and <=10 resources)
          |
          v
Backend -> addPolicy -> Imou Open Platform
          |
          v
Verification ledger / permission query

The desired-grant set is your source of intent. API calls are delivery attempts. Keeping those concepts separate makes retries and audits easier.

Six steps to provision safely

1. Resolve the sub-account. Store the Imou openid mapped to your application user. Policy operations use that identifier.
2. Build the desired grant set. Each row should contain a documented permission and a dev: or cam: resource. Avoid using a broader resource merely to reduce row count.
3. Apply inheritance deliberately. If all channels should receive a permission, record why a dev: grant is correct. Otherwise retain channel-level grants.
4. Chunk without changing semantics. Form addPolicy payloads with no more than 10 total devices or channels, no more than 10 statements, and no resource array longer than 10.
5. Send from a trusted backend. addPolicy requires openid, policy, and an administrator accessToken. Never place the administrator token or AppSecret in frontend code.
6. Verify and reconcile. Query effective access with queryDevicePermission or inventory assigned devices with listSubAccountDevice. Compare the result with your desired-grant ledger.

Example request body

The API envelope also requires the normal signed system fields. The permission-specific portion can look like this:

{
  "params": {
    "openid": "SUBACCOUNT_OPENID",
    "token": "ADMIN_ACCESS_TOKEN",
    "policy": {
      "statement": [
        {
          "permission": "Real,RecordReplay",
          "resource": [
            "cam:DEVICE123:0",
            "cam:DEVICE123:1"
          ]
        },
        {
          "permission": "Talk",
          "resource": [
            "cam:DEVICE456:0"
          ]
        }
      ]
    }
  }
}

This example does not claim that the listed devices support playback or talk. Authorization and capability remain separate checks.

A batching pattern

Pseudo-code helps make the constraints visible:

for each sub-account:
  grants = buildDesiredGrants(user)
  statements = groupByPermissionWithoutBroadening(grants)

  for each statementBatch where length <= 10
      and total resource references <= 10:
    ensure every statement.resource.length <= 10
    call addPolicy(openid, statementBatch)
    record result for reconciliation

If grouping creates more than ten statements, split them. If one permission group or the complete request contains more than ten resources, split the resource set. Preserve a stable operation identifier in your own job records so retries can be investigated. The documentation defines API parameters and limits; idempotent orchestration and reconciliation are application architecture recommendations, not promises from Imou.

Limits and pitfalls

1. Using dev: to avoid batching

That changes authorization scope. A shorter payload is not worth granting access to unintended child channels.

2. Assuming channel-to-device inheritance

The documentation says the cam resource belongs to dev and device permissions can pass to cam. It does not document the reverse. Keep a channel grant narrow.

3. Counting only resources

The addPolicy page explicitly discusses both the maximum authorized devices/channels and the statement/resource array lengths. Validate the total and both array dimensions at 10 or fewer.

4. Inventing permission names

Use only Alarm, Config, Ptz, Capture, Upgrade, Format, Real, RecordReplay, Talk, and DevControl. Product roles such as “viewer” belong in your own identity layer.

5. Treating success as permanent truth

Users move sites, devices are reassigned, and roles change. Reconcile policies and remove obsolete permissions with the account module’s removal interfaces.

6. Mixing administrator credentials into clients

Policy mutation is a backend responsibility. The administrator accessToken controls broad account resources and should not be distributed to a browser or mobile application.

Operational checklist

• [ ] Every dev: grant is intentional for child channels.
• [ ] Every channel-only role uses cam:DEVICE:CHANNEL.
• [ ] statement.length <= 10.
• [ ] Every statement.resource.length <= 10.
• [ ] Total devices or channels in the request <= 10.
• [ ] Permission names match the official vocabulary.
• [ ] Requests originate from the trusted backend.
• [ ] Effective permissions are verified after provisioning and role changes.

Register at Imou Open Platform to test the account APIs, then make inheritance and request-size checks explicit in your policy builder before applying it to a fleet.

Official sources

• Sub-account function description
• addPolicy: add sub-account permissions
• queryDevicePermission
• Account docking