A script receives Meraki webhook alerts for fifteen branch networks. When an offline-device alert arrives it must page the on-call engineer with the network and device names, while repeated copies of the same delivery are ignored. Which parsing and action plan handles this alert payload best?

Meraki delivers alert webhooks as a JSON body, and parsing it with the json module gives you named fields instead of brittle text matching. The alert id identifies the alert, so keeping a set of seen ids lets repeated copies of the same alert fall through untouched, while the alert type tells the script which condition fired and therefore what action to take. Network name and device name are included for applicable alerts, so the page names the exact box that needs attention. Scraping fields with regular expressions is less robust than using the structure the sender already provides and can break on formatting changes. Paging on every alert type fails because it removes the branching that separates an offline device from an informational notice, flooding the on-call engineer. Using the newest send time as the duplicate marker fails because timestamps are not unique to an alert, so distinct alerts that share a time can be silently dropped. Caveat: field sets differ between alert types, so guard against keys that are absent. Practical check: replay one captured payload twice and confirm only one page goes out.