A retail chain posts Meraki alert webhooks for every store network to a single Python endpoint through one configured HTTP server. Each JSON body carries sharedSecret, networkName, alertType and alertId. Only alerts from the Downtown store should page the on-call engineer, the shared secret must be checked before acting, and the endpoint replies 200 before the slow paging call runs. Which handler flow processes each incoming webhook payload correctly?
Select an answer to reveal the explanation.
Short Explanation
Parse the JSON body, then check sharedSecret before taking action—like checking a ticket before letting someone in. Reply 200 right away, and page the on-call engineer only when the alert is from Downtown.
Full Explanation
Meraki sends alert details in the webhook JSON body, so the endpoint can use those fields to make its decisions. Comparing sharedSecret with the configured value checks that the expected secret was supplied; checking networkName narrows paging to the Downtown store. Returning HTTP 200 before the pager runs acknowledges receipt without tying the response to a third-party service. Waiting until paging finishes delays the acknowledgement, while dispatching based on alert type alone can page for alerts from other stores. Branching on alertTypeId does not replace checking the shared secret. One shared destination for the organization can use the network name in each payload to identify the sending network. Practical check: replay a captured payload with curl -i and confirm the endpoint answers 200 quickly while paging only for Downtown.