A Python service receives Meraki alert webhooks over HTTPS. The JSON body carries the alert type, the device serial and the alert-specific details, and every outgoing team message must name both the alert type and identify the device using only the data in the payload. Which JSON parsing approach should the script use to route each Meraki webhook?
Select an answer to reveal the explanation.
Short Explanation
You can parse the request body with json.loads and use alertType to choose the action and deviceSerial to identify the device in the message. Dashboard or cached-inventory lookups add information from outside the payload, while sending every alert to one shared channel does not route by alert type.
Full Explanation
Parsing the request body as JSON exposes the alert-specific fields directly. Use alertType to select the handling action and deviceSerial to identify the device in the message; this keeps both routing and message construction grounded in the webhook payload. Looking up a friendly name in Dashboard may be a useful enrichment pattern, but it violates the requirement to identify the device using only payload data because the name comes from an external lookup. Resolving the serial through a cached inventory has the same conceptual flaw: caching changes how external data is obtained, not its source. Publishing every alert to one shared operations channel can still use the payload’s deviceSerial in the message, but it does not choose the outgoing action according to alertType. An exam caveat is that correct JSON parsing alone does not guarantee compliance: both the source of identifying values and the routing behavior matter. As a practical check, test webhook bodies for several alert types and verify that each resulting message names the alert type, includes the payload’s deviceSerial, and reaches the intended type-specific action without relying on lookup data.