Cisco Meraki Webhooks

When to Use This Skill

• Setting up Cisco Meraki Dashboard webhook (HTTP server) handlers
• How do I verify Meraki webhooks? / validating the Meraki sharedSecret
• Understanding Meraki alert types and payload structure
• Handling motion_alert, settings_changed, sensor_alert, or stopped_reporting alerts
• Why is my Meraki webhook sharedSecret check failing?

Verification (core)

Meraki does NOT use an HMAC signature header and does NOT follow the Standard Webhooks spec. There is no X-*-Signature header to check. Instead, Meraki puts a plaintext sharedSecret field inside the JSON request body. You verify by comparing that field against the shared secret you configured on the HTTP server (Dashboard → Network-wide → Alerts → Webhooks / HTTP servers).

The secret is optional and travels unencrypted, so TLS (HTTPS with a CA-trusted cert — no self-signed) is the real transport protection; the sharedSecret only proves the sender knows the value you set. Parse the body, then compare timing-safe.

Branch explicitly on whether a secret is configured. With none configured, both sides coerce to '' and every request passes with no warning — a silent fail-open. Unset means TLS-only (accept, but warn); set means the payload must carry a matching sharedSecret. See references/verification.md.

Node: