A retail chain wants foot-traffic analytics from its MR access points, and the analytics platform runs as an HTTPS service the team operates. The Location Scanning API must deliver observed wireless client data to that service without an analyst signing into the dashboard. Which delivery mechanism should the engineer configure for location scanning data?
Select an answer to reveal the explanation.
Short Explanation
Location scanning works as a push service instead of a report you download. The Meraki cloud takes what the access points observe and sends batches to the HTTPS address you registered in the dashboard, like a courier who only needs your street address. The key idea is push delivery, so there's no polling call to write.
Full Explanation
Access points observe wireless clients around them, and when Location Scanning is enabled for a network with a destination address, the Meraki cloud serializes those observations into JSON batches and POSTs them to that HTTPS endpoint periodically, often with a shared secret so your receiver can verify the source. A scheduled GET export fails because the scanning stream is not stored behind a retrieval endpoint for clients to download. General webhook alerts fail because that pipeline carries event notifications such as network alerts with a different schema, not scanning observations. Sampling the client status API fails because it reports only currently associated clients at a moment in time, giving you neither probe history nor the RSSI trail that location analytics need. Exam caveat: Bluetooth monitoring is a separate feature with its own settings, so do not assume one toggle covers both. Practical check: stand up a small HTTPS receiver, enable scanning on a test network, walk a phone past an access point, and confirm batches arrive with client MAC, RSSI and timestamp values your parser expects.