Recovering a Silent Imou Callback: HTTP 200, Reachability and Re-subscription

#camera #automation

Start recovery at the callback ingress, not at the device. Imou’s push guide requires the receiver to return HTTP 200 and warns that pushes can stop after the service fails to return the response multiple times. Verify public reachability and exact response codes, read the saved callback configuration, correct and re-enable it if needed, then generate a supported test event. The documentation publishes no retry count.

Why it matters

A silent callback can look like a device problem while every backend query remains healthy. It can also look like an Imou delivery problem when the request reached your edge but failed in parsing, a queue, or customer notification. Recovery becomes much faster when “delivery to ingress,” “acknowledgement,” “durable acceptance,” and “business processing” are separate observability stages.

The documented platform behavior is narrow but important: use an internet-accessible callback address, and return HTTP 200. The number, spacing, and backoff of failed attempts are not specified. A runbook that invents them creates false confidence and can delay escalation.

Approach / architecture

Use a thin callback path:

Imou Open Platform
  -> public HTTPS edge
  -> callback route
       -> bounded request checks
       -> durable enqueue
       -> HTTP 200
  -> asynchronous workers
       -> classify payload
       -> deduplicate
       -> retrieve optional media
       -> notify application users

This queue-first shape is application guidance, not a delivery guarantee from Imou. Its purpose is to remove slow or unreliable business work from the documented acknowledgement path.

Maintain four signals:

Signal	Question answered	Typical evidence
Edge requests	Did any request reach public infrastructure?	Load-balancer request record
HTTP 200	Did the callback satisfy the documented response?	Route status and response completion
Durable acceptance	Can the event survive worker failure?	Queue/store acknowledgement
Business completion	Did the user-facing action finish?	Worker and notification state

Seven recovery steps

Establish the last known good point. Compare the last ingress request, last returned 200, last persisted event, and last delivered notification. This prevents a downstream outage from being mislabeled as stopped pushes.
Probe from outside the private network. Verify DNS, TLS certificate chain, firewall, load balancer, route, and application process through the same public hostname configured with Imou. A browser test can hide redirects or authentication middleware, so inspect the actual status.
Check exact callback responses. The official guide says HTTP 200. Do not assume a redirect, 201, 202, 204, authentication challenge, gateway error, or timeout is equivalent. Review deployment changes that could add CSRF checks, login redirects, body limits, or synchronous processing.
Read platform configuration. Call getMessageCallback from a trusted backend. Compare returned status, callbackUrl, and callbackFlag with controlled configuration. Avoid relying on a screenshot or an old deployment variable.
Correct or re-subscribe deliberately. If configuration is wrong or delivery remains stopped after ingress health is restored, use setMessageCallback with an administrator accessToken, documented status, callback URL, flags, and applicable basePush. Record the authorized change; do not repeatedly toggle settings.
Generate a supported test event. Use a target device known to support an enabled event category. A quiet device, disabled detection, or unsupported event family does not test the transport.
Verify end to end. Confirm public receipt, HTTP 200, persistence, parsing, and final application action as separate checkpoints. Preserve UTC times, request identifiers, sanitized result codes, and the tested category for escalation.

APIs / SDKs

The event message push process is the canonical behavior source. It says events can be pushed to the developer’s backend callback, requires the callback service to return 200, and warns that the platform can stop pushing after multiple missing responses.

Use these documented interfaces:

getMessageCallback to inspect callback state, URL, and selected categories;
setMessageCallback to enable or disable subscription and set the internet-accessible callback;
the event format definition to validate the payload family used for testing; and
the event type definition to confirm documented event types.

Callback configuration is an administrator operation. Keep AppSecret and administrator accessToken in the backend. The public callback route should not expose those credentials.

Prevention and change control

Make callback health a deployment gate. Test the production hostname from an external probe, assert an exact 200 from the configured route, and verify a durable enqueue without invoking all business workers. Alert separately on non-200 responses, absence of ingress relative to known test activity, queue failures, unknown payload families, and notification errors.

Keep intended callback configuration in reviewed server-side configuration. Periodically compare it with getMessageCallback, especially after domain, certificate, proxy, or application migrations. Record who changed subscription state, which categories changed, how it was validated, and how to roll back.

Limits & pitfalls

Do not state a retry count, retry interval, backoff algorithm, or automatic restoration time. The cited page provides none.
Do not return a generic successful status other than 200 unless current documentation explicitly changes the requirement.
Do not acknowledge only after image downloads, database joins, or customer webhooks complete.
Do not assume no event means no delivery. Confirm device activity, enabled detection, category selection, and capability.
Do not repeatedly re-subscribe before fixing public reachability; that does not repair a broken ingress.
Do not let an unknown optional field make every callback fail. Preserve the bounded raw body and route parser failures for review.
Do not expose tokens, signed image URLs, device identifiers, or full payloads in support tickets.
Do not present queue design, idempotency, alert thresholds, or dead-letter behavior as Imou platform guarantees.
Recheck live callback documentation before publishing the runbook.

If recovery still fails after a healthy 200 path and verified configuration, prepare a factual escalation: developer account region, callback category, UTC test time, last successful time, sanitized configuration, request evidence from the edge, and redacted OpenAPI result IDs. Avoid unsupported conclusions about platform retry state.

Review the live Imou push process, then test your production callback as a small, observable ingress service before relying on downstream notifications.

DEV Community