How to integrate Imou camera? Treat integration as four layers: create an Open Platform application and bind devices; obtain accessToken on your BFF; sync inventory with listDeviceDetailsByPage into your tenant/site model; play with getKitToken + ImouPlayer (or bindDeviceLive / createDeviceRtmpLive for HLS/RTMP). Your product keeps ACL. Imou Open Platform delivers cloud video and AIoT APIs/SDKs—not your permission model.
If you are a product engineer on a security, retail, property, or field-ops SaaS, “integrate Imou camera” rarely means buying a consumer app deep link. It means cameras show up inside the same UI as sites, tickets, and roles—with audit trails your customers already trust.
The teams that ship cleanly do not start with a sixteen-tile video wall. They start with a boring Camera Detail Live tab and a hard credential boundary.
What “integrated” actually means
Customers judge integration by three questions:
- Can I open a site in your product and see the right cameras?
- Can only the right roles watch?
- Does live work without sending operators to another app?
Imou Open Platform answers device connectivity, streaming, and service entitlements. You answer product semantics. Confusing those two layers produces either black screens or security reviews you will not enjoy.
Explore the surface: Video Monitoring.
The four-layer path
1) Application and device binding
Register at https://open.imoulife.com, create an application, store appId/appSecret in a secrets manager. Bind cameras into the developer asset pool. Cameras that only appear in a consumer account are not automatically API-visible—binding is what makes inventory and live APIs work for your app.
2) Server auth (accessToken)
Your BFF calls accessToken, caches it, and refreshes per platform guidance. This token authenticates OpenAPI. It must never reach the browser, mobile binary, or public repo. Same rule for appSecret.
3) Inventory into your data model
Sync with listDeviceDetailsByPage (pageSize 1–50). Map deviceId and channel to your tenant and site tables. Product engineers should insist on this mapping before any dashboard mockup with live players—operators think in sites, not raw device IDs.
4) Short-lived play credentials
After your SaaS ACL says yes:
| Surface | Use |
|---|---|
| Interactive web |
getKitToken + ImouPlayer
|
| HLS URL / custom player | bindDeviceLive |
| RTMP pipeline | createDeviceRtmpLive |
| Native mobile | OpenSDK (Android / iOS) |
kitToken is for ImouPlayer (about 2 hours TTL; ~1 hour BFF cache is a practical pattern). Do not feed accessToken into the player. Quality: streamId 0 = HD, 1 = SD—default SD for multi-tile views.
Docs: JS SDK, Custom live broadcast.
What product engineers should put in the PRD
Write these as acceptance criteria, not as “nice-to-have security notes”:
-
Credential boundary. Browser and mobile clients receive only short-lived play credentials after ACL.
appSecretandaccessTokennever ship in client bundles. -
ACL ownership. Tenant/site/role checks happen in your product before any
getKitToken,bindDeviceLive, orcreateDeviceRtmpLivecall. -
Inventory ownership. Camera pickers read your ledger (synced via
listDeviceDetailsByPage), not a live mint storm. -
Concurrency policy. Dashboards use capped slots and SD defaults (
streamId = 1); HD (streamId = 0) is a focus action. - Capability honesty. Talk, PTZ, and cloud playback are gated on device + subscribed services—no invented SKUs or benchmark claims.
- Quota awareness. Live-view planning references My Resources; destroy players on close.
If a design mock shows sixteen HD tiles at login with PTZ on every cell, send it back. That mock is a bandwidth and entitlement fantasy, not a shippable milestone.
Architecture product engineers should defend
SaaS UI (tenant / site / role)
│
â–Ľ
Your BFF — ACL first, then OpenAPI
│
â–Ľ
Imou OpenAPI — devices, kitToken / live URLs
│
â–Ľ
Cameras (capabilities depend on device + subscribed services)
Non-negotiables in the PRD:
- ACL before minting any play credential
- No developer secrets in the SPA
- On-demand streams; destroy players on close
- Capability flags for talk/PTZ/playback only when verified
- Live-view planning against My Resources
Roadmap that survives a quarter
Sprint A — First live frame
Camera Detail → Live tab → one BFF endpoint → ImouPlayer SD. Acceptance: authorized users see video; unauthorized users get your 403 UX; no secrets in client bundles.
Sprint B — Site mapping
Admin attaches cameras to sites; site pages list cameras without opening streams.
Sprint C — Multi-camera slots
Fixed slot count, SD default, one HD focus, destroy on clear. Do not promise “all cameras HD forever.”
Sprint D — Optional protocol surfaces
HLS share links or RTMP only where product explicitly needs them—same ACL gate.
This order keeps design, security, and platform quota aligned. Jumping to Sprint C first is how uplinks and error budgets melt.
How to talk to stakeholders
To sales: “Cameras appear inside our product with our roles—not a consumer-app handoff.”
To security: “Developer secrets stay on the BFF; every live session is ACL-gated and short-lived.”
To eng leads: “One live-session contract; ImouPlayer first; HLS/RTMP only when the surface requires them.”
To customers: Capabilities depend on their devices and subscribed services—set expectations before the POC demo.
That language prevents the classic trap where a POC deep-links into a consumer app and then finance asks why “integration” still is not done three months later.
Pitfalls that look like “Imou issues”
- Pasting
accessTokeninto ImouPlayer → black screen (kitTokenâ‰accessToken) - One shared admin token for all tenants → multi-tenant incident waiting to happen
- Prefetching every live URL at login → quota and expired sources
- Roadmap promises for talk/PTZ/cloud playback without checking device and subscribed services
- Treating deep links into a consumer app as “SaaS integration”
- Measuring success as “player rendered” instead of “authorized user saw the right camera under our roles”
If you are scoping camera work for a B2B product, start from Video Monitoring and register at https://open.imoulife.com. Imou Open Platform is cloud video and AIoT focused, with APIs, SDKs, and low-code components to help vendors and developers ship video features inside the products customers already live in—without rewriting your ACL model. Build the Live tab on a page you already own, keep secrets on the BFF, and grow from one frame to a site wall without changing the trust boundary.
