A national retail chain wants its own analytics database to hold the device observation records that Meraki MR access points collect in each store. The data team prefers a push model over dashboard polling and needs batches delivered to infrastructure they host, with no manual export step. Which delivery design matches how the Location Scanning API hands over observation data?
Select an answer to reveal the explanation.
Short Explanation
The Location Scanning API is a push feed: you register a receiving URL and Meraki posts each batch to you. It works like a scheduled delivery rather than a shopping trip, because your collector just sits still and waits for the next batch. There's no polling loop and no manual export to schedule.
Full Explanation
The Location Scanning API is designed to send observation records to a receiver that you configure: Meraki posts batches over HTTPS on its own cadence. Hosting that receiver lets the chain ingest the data directly into its infrastructure without polling the dashboard or manually exporting files. Network-event webhooks are also a push-based integration, but they carry event notifications such as status changes, not the device observation records required here. A vendor-managed collector can accept and forward observations, but it places the receiving infrastructure outside the chain’s control, contrary to the requirement that batches be delivered to infrastructure the chain hosts. Scheduled Dashboard API retrieval is a familiar way to collect available client data, but it is a pull design: the chain initiates requests rather than receiving Meraki’s cadence-driven posts. Exam caveat: distinguish the Location Scanning API’s observation payloads from general network webhooks and dashboard client data; similar terms do not imply equivalent data or delivery semantics. Practical check: before deployment, verify that the configured HTTPS receiver can accept the expected batch format, authenticate requests as required, and handle retries or duplicate deliveries safely.