A civic location receiver is configured in Meraki Dashboard, but no observations arrive. Meraki first GETs the POST URL during setup. What must the receiver return for that handshake?
Select an answer to reveal the explanation.
Short Explanation
Before the firehose starts, Meraki knocks with a GET and expects you to say back the validator passphrase. A 200 with the wrong body—or a receiver that only handles POST—fails the handshake.
Full Explanation
When a civic location receiver is first configured in Meraki Dashboard, Meraki validates the POST URL with an HTTP GET probe and expects a precise handshake response. The receiver must return HTTP 200 whose body echoes the exact validator string configured for that network in Dashboard—byte-for-byte as set on the Scanning/location settings. Only after that echo succeeds will the Meraki cloud begin delivering observation POSTs to the endpoint for Wi-Fi and BLE sightings.
Returning HTTP 200 with an empty body fails the handshake even if your POST handler is perfect—Meraki requires the validator echo on the GET probe before the firehose starts. Responding with HTTP 401 and a Webex bot token challenge page fails because this probe is Meraki’s validator check, not a Webex OAuth or bot authentication dance. Redirecting to api.meraki.com/login so Meraki can collect a browser cookie fails headless automation and does not satisfy the documented validator response contract.
Exam caveat: validators are per-network configuration; rotating the validator in Dashboard without updating the receiver breaks an otherwise healthy POST path and looks like “no observations” outages.
Operational check: temporarily distinguish GET versus POST in receiver logs, trigger Dashboard validation, assert GET returns 200 with the exact validator string, then confirm observation POSTs begin arriving for a test walk.