Meraki webhooks and sample webhooks schemas.

Meraki Webhooks are a powerful and lightweight new way to subscribe to alerts sent from the Meraki Cloud when an event occurs.


Meraki Webhooks are a powerful and lightweight solution to send networks alerts to a remote service.

These messages are sent to a unique URL where they can be processed, stored or used to trigger automations. For a comprehensive list of alerts, please see the Webhook Sample Alerts section of this doc or use the Dashboard API Alert Types endpoint to get the most up to date list.

Setup and Configuration

Add an HTTP Server

Add one or more HTTP servers. Include a name, unique HTTPS (TLS) URL and shared secret (see Security below for more details). You can optionally select a payload template.

Network-wide --> alerts

Assign Alerts

Configured HTTP servers can be selected as a recipient (destination) for any alert within dashboard, or via the alert configuration endpoint via API.

Common JSON Parameters

Name Format Description
alertData object Object of unique parameters for each alert
alertId string ID for this alert message
alertType string Type of alert (“Network usage alert”, “Settings changed”, etc.)
networkId string ID for the Meraki network
networkName string Name for the Meraki network
networkUrl string (URL) URL of the Meraki Dashboard network
occurredAt UTC Timestamp of the alert
organizationId string ID of the Meraki organization
organizationName string Name of the Meraki organization
organizationUrl string (URL) URL of the Meraki Dashboard organization
sentAt UTC Timestamp of the sent message
sharedSecret string User defined secret to be validated by the webhook receiver (optional)
version float Current version of webhook format


Securing data in transport

Webhook HTTP server URLs must use a TLS-enabled HTTPS URL located on a public server with a valid SSL certificate.

Shared Secret

  • The optional sharedSecret parameter is defined when configuring the HTTP server on the Meraki Dashboard. The value of the sharedSecret can be evaluated by the webhook receiving service before saving the information. If the webhook receiver does not support this option, the parameter will simply be ignored.
Example logic to evaluate the sharedSecret parameter
if (meraki.sharedSecret === "asdf1234"){
     // invalid secret

HTTP deprecation notice

As part of Cisco Meraki's efforts to continually improve our platform and enable customers to securely deploy Meraki networks, an update is being implemented to the Webhook services and configuration options.

What is changing?

Beginning May 22nd, 2019 Meraki will require all newly-configured receivers to use HTTPS and will no longer support configuring non-HTTPS receivers. All currently active Webhook services have until August 20, 2019 to upgrade receiver(s) configurations to HTTPS (SSL/TLS).

Will existing receivers stop working?

The option to use non-secure receivers will end on August 20, 2019, after which all active non-HTTPS receivers will be disabled. All newly configured receivers will be required to use HTTPS (SSL/TLS). In order to avoid any impact to services and applications using the Webhooks API, please make these changes on or before August 20, 2019. If you have not made the required changes by August 20, 2019 we will stop sending data to any remaining HTTP receivers.

Are self-signed SSL/TLS certificates supported?

Self-signed certificates are not supported for webhooks. The receiving web server must have a valid SSL/TLS certificate, signed by a globally trusted certificate authority (CA).

Need a certificate?

Consider one of these free or low-cost solutions for obtaining a certificate:

  • Let's Encrypt - Free SSL certificates
  • ngrok - Instant local secure proxy, ideal for development.


  • The Meraki Alerts will vary in delivery times. This will depend on the nature of the event and any configurable options. The occurredAt parameter can be used to derive the time the reported alert occurred at, which will often differ from the sentAt value.
  • On average, an alert will be sent within 90 seconds of the event.
  • Many alerts have a configurable threshold, such as waiting 5 minutes of downtime before the message will be sent.
  • Some alerts require additional computational time or aggregate multiple events. This will cause additional delays, but will likely not exceed 10 minutes.
  • Experiences may vary, so it’s best to test with your own environment to ensure it fits your needs.



Use the Postman collection to examine several sample alert messages and send them on demand for testing.

Postman Collection

Example Integrations