Why Imou Stopped Pushing to Your Callback URL

Imou event pushes can stop when your callback service repeatedly fails to return HTTP 200. The official push instructions require a 200 response and warn that, after multiple missing responses, the platform will no longer push to that callback address. Check receiver availability and the saved callback configuration first; the documentation does not publish a retry count or backoff schedule.

Why It Matters

This failure often hides behind an apparently healthy application. Devices remain online, API queries work, and the callback URL still exists, yet no new events reach downstream users. Treat callback acknowledgement as a production dependency with its own monitoring, deployment controls, and recovery procedure.

The documented fact is narrow: the receiver must return HTTP 200, and multiple failures can cause pushes to stop. Retry quantity, timing, backoff, and automatic recovery behavior are not specified on the linked page and must not be invented.

Architecture

Imou Open Platform
  -> public callback ingress
       -> minimal validation
       -> durable enqueue
       -> HTTP 200
  -> workers
       -> normalize / deduplicate / notify

The ingress should finish quickly. Database joins, image downloads, customer webhooks, email, and mobile notifications belong after a durable queue. This design is an application recommendation that helps your receiver return 200 reliably; it is not an Imou delivery guarantee.

Recovery Steps

1. Test the callback from outside your network. Confirm DNS, TLS certificate chain, routing, firewall, load balancer, and application process health. A localhost, VPN-only, or intranet address is not sufficient.
2. Inspect actual response codes. The official requirement is HTTP 200. A redirect, authentication challenge, rate-limit response, generic 2xx response other than 200, timeout, or gateway error should not be assumed acceptable.
3. Check recent deployments. Middleware can introduce CSRF checks, login redirects, body-size limits, content-type rejection, or synchronous work that prevents the required response.
4. Read saved callback configuration. Use getMessageCallback to verify status, callbackUrl, and callbackFlag. Confirm status is on and that required categories remain selected.
5. Correct configuration if necessary. Use setMessageCallback from a trusted backend with an administrator accessToken. Use only documented fields and flags.
6. Generate a supported test event. Verify that the target device and enabled capability can produce the selected event. A quiet device is not proof of broken delivery.
7. Confirm end-to-end processing. Separate “request reached ingress,” “HTTP 200 returned,” “event persisted,” and “notification delivered” metrics. A worker failure should not be misdiagnosed as missing Imou pushes.

If receiver health and configuration are correct but delivery does not resume, preserve timestamps and redacted request evidence for human investigation. Do not repeatedly toggle settings or expose credentials in a support bundle.

APIs and Official Documentation

• Event message push process: states that the developer callback service must return HTTP 200 and warns that the platform can stop pushing after multiple missing responses.
• getMessageCallback: reads the current callback status, URL, and selected callback identifiers.
• setMessageCallback: sets callback state and categories; it requires an internet-accessible callback URL when enabled.
• Event message format definition: provides the documented payload families used to validate test traffic.

These links define behavior cited here. There is no published retry table in them, so operational dashboards should report observed timing without presenting it as a platform contract.

Limits and Pitfalls

Do not invent retry behavior. Avoid claims such as “three failures,” “five retries,” “exponential backoff,” or “automatic restart after an hour.” The official page says only “multiple times” before pushes can stop.

Do not acknowledge after all business processing. A slow image fetch or customer notification can turn a valid callback into a timeout. Persist the event durably, return 200, and process asynchronously. The queue design is your responsibility.

Do not return a convenient substitute. The documented response is 200. Framework defaults such as 201 or 204 should be changed for this endpoint unless live documentation says otherwise.

Do not overlook redirects. HTTP-to-HTTPS redirects, trailing-slash redirects, and identity-proxy redirects can make a URL look reachable in a browser while failing the callback contract.

Do not confuse absence of events with stopped delivery. Confirm device activity, callback categories, and message-family support. Not every device produces every alarm or intelligent event.

Do not let malformed events poison ingress. Preserve a bounded raw payload, enqueue it, and move parsing failures to a dead-letter workflow. Returning non-200 for every unknown optional field can create an avoidable failure loop. This is architecture guidance, not a statement about platform retry semantics.

Do not expose secrets during diagnosis. Redact accessToken, appSecret, signed image URLs, and customer identifiers. Callback configuration changes use an administrator token and belong on a trusted backend.

Prevention Checklist

• Alert on non-200 callback responses and latency before application workers run.
• Use synthetic external health checks that exercise the same load balancer and middleware.
• Deploy callback changes gradually and keep a rollback path.
• Monitor queue age, parsing failures, dead-letter volume, and event-to-notification latency separately.
• Periodically compare saved callback configuration with intended configuration.
• Keep runbooks factual: HTTP 200 and possible stop after repeated failure are documented; retry counts and backoff are unknown.

Register at Imou Open Platform to build with its cloud-video and AIoT APIs and SDKs, and use the live push documentation as the final authority when operating your callback receiver.