Receive device messages

Scope and prerequisites

Your backend needs motion alarms, device online and offline changes, or standard capability events. The callback URL must be reachable from the public internet. You already created an app and have an administrator accessToken. See Create an app.

Overseas delivery does not include message-channel pull. Do not implement pullMessages or consumer groups.

Steps

1. Provide an HTTPS URL that is reachable from the public internet and returns an HTTP 2xx success response for each POST (200 is typical). Status codes 200–399 are treated as success; timeouts or other status codes count as failures. After repeated failures to get a valid response, the platform stops posting to that URL.
2. Call setMessageCallback. When status is on, set callbackUrl and callbackFlag. Separate flags with commas. Include the ones you need: alarm, deviceStatus, numberstat, faceAnalysis, capabilityEvent (listed in the API parameter table and in Device messages).
3. Parse the body. alarm and deviceStatus use did, cid, and a string msgType. For capabilityEvent, msgType is the eventId, and the body includes deviceId and outputData. For alarm and deviceStatus, types are in Event message types (see also legacy msgType table); legacy payload formats are in Event message format (legacy payload copy). For capabilityEvent, use the Event index and Event message format.
4. Forward to your application only after your backend has finished handling the message. Deduplicate with the id in the message.

Fields are defined on the API page. See Event message types for callbackFlag and legacy msgType values; payload formats are in Event message format. APIs: Push configuration.

Related reference

• Device messages
• Receive alarm messages
• setMessageCallback
• getMessageCallback