How can I add live video to my SaaS product?

Direct Answer

Add live video to an existing SaaS UI with one backend flow: authorize the user in your product ACL, obtain accessToken on the BFF, mint a short-lived kitToken via getKitToken, and render ImouPlayer in the page. Optionally issue HLS with bindDeviceLive for custom players. Never place appSecret or accessToken in the browser—only the play credential reaches the client after ACL checks.

Why it matters

Many teams already have tenants, sites, and roles. They do not need a full “platform rewrite” to show a live camera. They need a narrow embed path: when a user opens Camera Detail or a Live tab, the product proves permission, your BFF talks to Imou OpenAPI, and the UI plays video. Keeping that flow small reduces security mistakes and shipping time.

This FAQ is deliberately narrower than a full SaaS video encyclopedia. It assumes you can already identify which camera belongs to which site. The job here is embedding live into a screen you already own—without leaking developer secrets or bypassing your ACL.

Embed-focused flow

User opens Live in SaaS UI
  → SaaS session + ACL (tenant / site / role / camera)
  → BFF: accessToken (cached) → getKitToken(deviceId, channelId, ...)
  → UI: ImouPlayer.init({ kitToken, streamId, ... })

Optional branch after the same ACL check:

BFF: bindDeviceLive(...) → return HLS URL → custom HLS player

Use ImouPlayer when you want the Light App experience in-product. Use HLS when you already standardized on a third-party or in-house HLS client. Do not expose either path without the ACL gate.

Steps

1. Prerequisites. Application created on open.imoulife.com, devices bound to the developer asset pool, and camera IDs stored in your SaaS (often via listDeviceDetailsByPage earlier in the project with pageSize 1–50).
2. Add a Live entry point. A button or route in your product that already knows tenantId, siteId, and deviceId/channelId. Keep the route behind your normal authentication middleware.
3. Authorize first. On the BFF endpoint (for example POST /api/cameras/:id/live-session), verify the session and ACL. Reject before any Imou call if the user cannot view that camera. Return a generic 403—do not leak whether a camera exists in another tenant.
4. Mint kitToken. With server-side accessToken, call getKitToken for the authorized device/channel. Cache kitToken about 1 hour; TTL is about 2 hours per JS documentation. Return only { kitToken, expiresAt, streamId } to the client.
5. Render ImouPlayer. Load the Light Application JS SDK, set Wasm paths as documented, and initialize with kitToken—not accessToken. Prefer streamId = 1 (SD) unless the screen is a single HD focus view (streamId = 0).
6. Optional HLS path. If you already use a standard HLS player, call bindDeviceLive on the BFF after the same ACL check and return the URL. Treat it as a secret: short TTL pages, authenticated fetch, and no public CDN of live addresses.
7. Tear down cleanly. Destroy the player on route leave; refresh credentials before expiry if the session is long-lived. If the user switches cameras, mint for the new camera only after ACL, and destroy the previous player first.

APIs and SDKs

Native mobile clients follow a parallel pattern with OpenSDK: still authorize in your backend, still keep appSecret off the device when possible, and follow the SDK guides for play sessions.

Security checklist for the Live tab

• ACL evaluated on every live-session request
• accessToken cached only on the server
• Browser receives kitToken (or gated live URL) only
• No appSecret in frontend env files committed to git
• Live-view quota monitored in My Resources
• UI controls for talk/PTZ shown only when device and services support them

Pitfalls

• Shipping appSecret or long-lived admin tokens to the SPA.
• Passing accessToken into ImouPlayer (kitToken is required).
• Skipping SaaS ACL because “OpenAPI already authenticated the app.”
• Prefetching live sources for every camera on the list page.
• Ignoring live-view quota and subscribed service limits.
• Assuming talk, PTZ, or cloud playback always exist—capabilities depend on device and services.
• Reusing one kitToken across tenants or unrelated users after a cache key mistake.