Open Platform Q&A

Q1: What information is required for the first Open Platform integration?

Prepare the appid/openid assigned by the Open Platform, the internal server-side secret, and a device ID or IMEI. The internal server-side secret must be stored on the server or in a secure configuration center. Do not place it in a frontend page, app, or mini program, and do not pass it as an external request parameter.

Q2: Must both device_id and IMEI be provided?

No. The documentation states that either device_id or IMEI can identify a device, and at least one must be provided. In practice, keep the selected field consistent with the API documentation.

Q3: Where should sign be generated?

sign must be generated on the server. The frontend should call only your own server API to obtain timestamp, nonce, and sign. The server reads the secret using openid / device_id and generates the signature, avoiding bypass risks caused by accepting the internal server-side secret from outside.

Q4: How long is a WebRTC URL valid?

WebRTC stream URLs are used for live preview and usually have an expiration limit. Fetch them on demand instead of caching playback URLs for a long time.

Q5: How should a failed WebRTC URL request be troubleshot?

First confirm that the device has been added to the Open Platform. Then check the device ID, device password, timestamp, nonce, and sign. An offline device can also prevent the live stream from being obtained.

Q6: Why are device online/offline messages delayed?

Online/offline status depends on the device connection and platform detection, so a short delay may occur after the device is powered on or off. The business side should combine callback messages with active queries.

Q7: How should alarms, heartbeats, and GS/GE reports be received?

The developer must provide an HTTPS callback URL. The platform pushes events as POST JSON. The server should return a success result promptly and save the original data for traceability.

Q8: Does the callback API need to verify sign?

Yes. Fields such as timestamp, nonce, and data in the callback must participate in signature verification according to the documentation. Process the business event only after verification succeeds.

Q9: What is the difference between an RTSP stream URL and WebRTC?

WebRTC is better suited to low-latency preview in web pages. RTSP is better suited to traditional streaming, NVR, or server-side pulling. RTSP usually depends on the device network and plaintext password parameters.

Q10: What order is recommended for API debugging?

For joint debugging, follow this order: "Sign Generation Example -> Device Management -> Get WebRTC URL -> Event Callback". For GS3/GE1 devices, also read the GS/GE Device Integration Documentation.