Setting Up Imou Event Callbacks: status, callbackFlag and basePush Explained

Use the Imou Open Platform setMessageCallback interface from your trusted backend with an administrator accessToken. Set status to on, provide an internet-reachable callbackUrl, select one or more currently documented callbackFlag values, and choose basePush as documented. Treat those fields independently: subscription state, callback categories, and basic notifications are separate configuration decisions.

Why It Matters

An event integration can look healthy because the callback URL was saved while still receiving the wrong categories—or nothing at all. The safest setup is to map each documented field to one explicit operational decision, verify the stored configuration, and test the receiver before relying on it for user notifications or incident workflows.

This answer intentionally uses only values shown on the current setMessageCallback documentation. It does not infer additional flags or promise that every device produces every event.

Architecture

Device
  -> Imou Open Platform event service
  -> public HTTPS callbackUrl on your backend
  -> fast validation and durable queue
  -> application notifications / workflows

Keep appSecret and the administrator accessToken in a trusted backend. The callback endpoint is also a backend service: it should not be a browser route, a developer laptop, or a private intranet address.

The three configuration controls have different jobs:

Field	Documented role	Safe interpretation
status	Whether to subscribe; legal values are on and off	on enables the configured subscription; off disables it
callbackFlag	Selects callback categories, separated by commas	Use only categories listed on the live interface page
basePush	Basic-notification control; 1 means push and 2 means no push	Decide explicitly; do not assume it is another event category

The current interface page lists these callbackFlag values: alarm, deviceStatus, numberstat, and faceAnalysis. The page describes them respectively as device alarm messages, device online/offline messages, passenger-flow data, and face-intelligence messages. Recheck that page before publication and deployment because the live documentation remains authoritative.

Setup Steps

1. Create a backend callback endpoint. Give it a stable internet-reachable URL. Use TLS, validate request shape, limit request sizes, and redact sensitive data from logs.
2. Choose the categories your product actually consumes. For alarms and online/offline changes, for example, use the documented comma-separated selection alarm,deviceStatus. Do not add guessed labels.
3. Choose basePush deliberately. The interface documents 1 as push and 2 as no push, with 2 shown as the default. Keep this decision separate from callbackFlag.
4. Call setMessageCallback on the backend. When status is on, the documentation requires callbackUrl and callbackFlag. The request uses an administrator accessToken.
5. Read the stored configuration. Use getMessageCallback to verify status, callbackUrl, and callbackFlag rather than trusting local configuration alone.
6. Exercise a real supported event path. Confirm that the selected device and capability can produce the event. Device support and service availability can vary.
7. Acknowledge promptly, then process asynchronously. The push instructions require the callback service to return HTTP 200. Put durable work behind a queue so slow application processing does not delay that response.

APIs and Official Documentation

• setMessageCallback: saves the callback configuration and documents status, callbackUrl, callbackFlag, and basePush.
• getMessageCallback: reads the callback address information currently stored for the developer account.
• Event message push process: explains delivery to the developer backend and the HTTP 200 requirement.
• Event message format definition: shows that payload shapes vary by message family.

These pages are the source of truth. A copied request in an old integration note is not a contract for future flags or payloads.

Limits and Pitfalls

Do not treat all callbacks as alarms. deviceStatus, traffic statistics, and face-analysis messages can have different shapes from general device alarms. Route by documented message structure and tolerate optional fields.

Do not invent flag aliases. Only the values currently listed by setMessageCallback are asserted here. A device event type such as a particular msgType is not automatically a valid callbackFlag.

Do not assume basePush replaces callbackFlag. The interface exposes both fields. Preserve that distinction in configuration screens and deployment manifests.

Do not expose administrator credentials. The setup call belongs on the backend. Never put appSecret or an administrator accessToken in frontend code, mobile configuration, logs, or support screenshots.

Do not use an unreachable URL. The interface requires an address accessible from the internet. Network allowlists, certificate problems, redirects, authentication middleware, or maintenance pages can prevent successful delivery even when DNS resolves.

Do not perform heavy work before acknowledging. Persist enough information to process safely, return HTTP 200 as required, and continue through a queue. Idempotency and durable queuing are architecture recommendations from your application design; they are not platform delivery guarantees.

Do not promise universal event support. Selected flags describe categories the platform can push. Actual messages still depend on the device, channel, enabled features, and applicable services.

Register at Imou Open Platform to evaluate its cloud-video and AIoT APIs and SDKs, then validate callback behavior against the current documentation and your target devices before release.