How to Use the Cisco Meraki Dashboard API
Click 日本語 for Japanese
Learn more with these free online training courses on the Meraki Learning Hub:
Overview
This article explains how to use the Cisco Meraki Dashboard Application Programming Interface (API), an interface for software to interact directly with the Meraki cloud platform and Meraki-managed devices. The API contains a set of tools known as "endpoints" for building software and applications that communicate with the Meraki dashboard.
The Dashboard API is a modern, RESTful API that uses HTTPS requests to a URL and JSON as a human-readable format. It is an open-ended tool that serves many purposes, including provisioning, bulk configuration changes, monitoring, and role-based access controls.
Meraki customers use the dashboard API to:
- Add new organizations, admins, networks, devices, VLANs, and Service Set Identifiers (SSIDs).
- Provision thousands of new sites in minutes with an automation script.
- Onboard and off-board new employees' teleworker devices automatically.
- Build a custom dashboard for store managers, field techs, or other unique use cases.
API call volume is rate-limited to ten calls per second, per organization.
Prerequisites
-
A Meraki dashboard account. The Dashboard API is enabled by default on all organizations.
-
Organization administrator access to configure API keys and webhooks. The API & Webhooks page is currently visible only to organization administrators.
-
A non-SAML/SSO account to generate API keys. SAML users cannot generate API keys, which upholds security requirements.
API Analytics (the first tab on the API & Webhooks page) is visible to all organization admins, but the ability to generate API keys is restricted as noted above.
Step-by-step instructions
Generate an API key
You can generate an API key from either the API & Webhooks page or the My Profile page. The API key associates with the dashboard administrator account that generates it and inherits the same permissions as that account. You can generate, revoke, and regenerate your API key on your profile.
Cisco Meraki Dashboard API is enabled by default on all organizations.
Generate an API key from the API & Webhooks page
-
Log in to the Meraki dashboard.
-
Go to Organization > Configure > API & Webhooks.
-
Select the API keys and access tab.
-
Select Generate API Key.

The three tabs on the API & Webhooks page are:
- API analytics
- API keys and access
- Webhooks

Generate an API key from the My Profile page (alternative method)
-
Select the avatar icon in the top right-hand corner of the dashboard to open the My Profile page.
-
Generate your API key from the API Access section.

-
Copy and store your key safely.

Understand the API key lifecycle
Keep your API key safe, because it provides authentication to all of your organizations with the API enabled. For security reasons, the dashboard does not store API keys in plain text, so the moment you generate the key is the only time you can record it. If you lose or forget your API key, revoke it and generate a new one.
Key lifecycle behaviors:
-
Two API keys per user profile: After you generate two keys, the Generate API key button is disabled. Revoke one of the generated keys before you generate a new one.
-
SAML/SSO administrators cannot view or generate API keys.
-
API keys can access all organizations the administrator has access to. If an admin generates an API key and has access to multiple orgs, the key can access all of them.
-
API keys do not expire. An administrator's expiring password does not affect their API key; the key still works regardless of the admin's password status.
Make API requests
Every request must specify an API key via a request header, and the API version must be specified in the URL.
Authorization: Bearer <secret key>
Specify the API version in the URL:
https://api.meraki.com/api/v1/<resource>
Use the correct base URL for your dashboard region:
- China dashboard: api.meraki.cn
- Canada dashboard: api.meraki.ca
- India dashboard: api.meraki.in
- Government dashboard: api.gov-meraki.com
The API returns 404 (rather than 403) in response to a request with a missing or incorrect API key. This prevents leaking the existence of resources to unauthorized users.
API verbs
Verbs in the API follow the usual REST conventions:
- GET returns the value of a resource or a list of resources, depending on whether an identifier is specified.
- GET of /v1/organizations returns a list of organizations.
- GET of /v1/organizations/<org_id> returns a particular organization.
- POST adds a new resource and performs other non-idempotent changes.
- POST to /v1/organizations/<org_id>/admins.
- PUT updates a resource. PUT is idempotent; it updates a resource but does not create one if it does not already exist, which differs from RFC 9110. Specify all the fields of a resource, because omitted fields have no changes made to their value.
- DELETE removes a resource.
Note: Call volume is limited to ten calls per second, per organization.
Stricter rate limit for claim endpoints
The following endpoints are subject to a stricter rate limit of 10 requests over a 5-minute period, per IP address:
- POST /api/v1/organizations/{organizationId}/inventory/claim
- POST /api/v1/organizations/{organizationId}/claim
- POST /api/v1/networks/{networkId}/devices/claim
When this rate limit is reached, the API returns an HTTP 429 error and sets the Retry-After response header to the number of seconds you must wait before accessing the endpoint again.
Handle identifiers
Identifiers in the API are opaque strings. A <network_id>, for example, might be the string "126043", whereas an <order_id> might contain characters, such as "4S1234567". Do not parse identifiers as numbers. Even identifiers that look like numbers might be too long to encode without loss of precision in Javascript, where the only numeric type is IEEE 754 floating point.
Example requests
These examples are not comprehensive. For a comprehensive list of API endpoints and their details, refer to the Meraki Developer Hub.
Organizations
Retrieve the list of organizations for the API key specified in the authorization header:
GET https://api.meraki.com/api/v1/organizations
Response code: 200
Response body: [{"id":"<org_id>","name":"<org_name>" }]
A 302 response code may occur on any API call, including those that modify state such as DELETE, POST, and PUT. When a GET is redirected, the status code is 302. When a non-GET is redirected, the status code is 307 for Postman or 308 for any other client. Client applications must follow these redirects. The host issuing the redirect takes no action, so even non-idempotent requests are safe to retry on the new host.
Most HTTP libraries and clients only follow a redirect with the HTTP verb GET. If you use other HTTP verbs, they may still follow the redirect but substitute GET for the other verb. As a result, a redirect on DELETE, POST, or PUT may look as though a GET was requested. To avoid this:
-
Perform a GET on the organization you are working with.
-
Store the URL you are working with.
-
Use the URL for subsequent requests, particularly those that modify state.
Retrieve metadata about a specific organization:
GET https://api.meraki.com/api/v1/organizations
Response code: 200
Response body: [ {“id”: <org_id>, “name”: “Test Organization” } ]
Create a new organization:
POST https://api.meraki.com/api/v1/organizations
Request body: { “name”: “Second Test Organization” }
Response code: 201
Response body: { "id": <new_org_id>, name: "Second Test Organization" }
The new organization is unconfigured. The admin who created it has full organization write access. Clients of the API can add additional admins and then remove the creating admin from the new organization if desired.
The API does not allow clients to remove the last remaining admin with full organization write access, because doing so could lead to an unconfigurable organization.
Networks
List the networks in an organization:
GET https://api.meraki.com/api/v1/organizations/<new_org_id>/networks
Response code: 200
Response body: [ { "id": <network_id>, "name": "Test Network", "organization_id": <new_org_id>, "type": "wireless",
"timeZone": "America/Los_Angeles", "tags": " test "}]
Create a new network:
POST https://api.meraki.com/api/v1/organizations/<org_id>/networks
Request body: { “name”: “Test Network 2”, “organizationId”: <org_id>, “type”: “appliance”}
Response code: 201
Response body: { “id”: <network_id>, “name”: “Test Network 2”, “organization_id”: <org_id>, “type”: “appliance”, “tags”: null }
Valid network types are appliance, switch, wireless, systemsManager, or camera. Use a combination of these to create a combined network. For example, "type": "appliance wireless".
Licenses and devices
Claim a device, license key, or order into an organization. When you claim by order, all devices and licenses in the order are claimed. Licenses are added to the organization, and devices are placed in the organization's inventory. These three claim types are mutually exclusive and cannot be performed in one request.
The licenseMode parameter can be either renew or addDevices. addDevices increases the license limit, while renew extends the amount of time until expiration. This parameter is required when claiming by licenseKey. For more information, refer to this article.
POST https://api.meraki.com/api/v1/organizations/<org_id>/ claim
Request body: { "order": "4CXXXXXXX" }
Response code: 200
Response body: <empty>
SNMP settings
Set the SNMP settings for an organization. The community string for SNMPv2 is in the response and can also be retrieved via a GET to this same URL
GET https://api.meraki.com/api/v1/organizations/<org_id>/snmp
Request body: { "v2cEnabled": true, "v3Enabled": true, "v3AuthMode": "SHA", "v3AuthPass", <secret>, "v3PrivMode": "AES128", "v3PrivPass": <secret>, "allowedIPs": ["5.6.7.8"] }
Response code: 200
Response body: { "v2Enabled": true, “v2CommunityString”: <secret>, "v3Enabled": true, "authMode": "SHA", "authPass", <secret>, "privMode": "AES128", "privPass": <secret>, "allowedIPs": ["5.6.7.8"] }
Administrators
List the administrators for an organization:
GET https://api.meraki.com/api/v1/organizations/<org_id>/admins
Response code: 200
Response body: [ { "name": "Jane Doe", "email": "jane@doe.com", "orgAccess": "full","id": <admin_id> } ]
Organization access can be full, read-only, or none.
Add a new administrator with rights to only one network:
POST https://api.meraki.com/api/v1/organizations/<org_id>/admins/
Request body: { "name": "John Doe", "email": "john@doe.com", "orgAccess": "none", "networks": [{ "id": <network_id>, "access": "full" }
Response code: 201
Response body: { “id”: <admin_id>, "name": "John Doe", "email": "john@doe.com", "orgAccess": "none", "networks": [{ "id": <network_id>, "access": "full" }]
Valid access levels for networks are full, read-only, monitor-only, and guest-ambassador. Clients can also give administrators access by tag by substituting the networks field for tags such as:
"tags": [{ "tag": "foo", "access": "read-only" }],
Valid access levels for tags are the same as for networks. Clients can update administrators using PUT and specifying an admin_id.
Delete an administrator:
DELETE https://api.meraki.com/api/v1/organizations/<org_id>/admins/<admin_id>
Response code: 204
Response body: <empty>
Monitor API usage with API Analytics
API Analytics gives organizations visibility into their Dashboard API consumption. It helps you understand which integrations or custom applications interact with your environment programmatically, and it gives developers detailed insights into how well their applications perform so they can optimize them.
The data on this page originates from the following API operations:
- getOrganizationAdmins
- getOrganizationApiRequests
- getOrganizationApiRequestOverview
- getOrganizationApiRequestOverviewResponseCodesByInterval
Access API Analytics
-
Log in to the Meraki dashboard and hover over Organization on the left navigation.
-
Under Configure, select API & Webhooks. API analytics is the first tab you land on.

This page is visible to all org admins.
Review the modules
The page has three modules (sections) that help you monitor your organization's API consumption:
Overview cards
The Overview section provides at-a-glance summary cards that affirm your applications' overall health over the last 24 hours:
- The number of total requests and their breakdowns.
- The number and relative percentage of successful requests.
- The number and relative percentage of rate limit hits (HTTP responses with 429 codes). For more information on how Dashboard API rate limits work, refer to the rate limit documentation.
- The number and relative percentage of other errors (HTTP responses with 400 codes except 429).
You can also see the relative percentage change from the previous day to understand how errors increased or decreased.
The relative percentage change from the previous day is calculated as: the sum of errors over the most recent 24 hours minus the sum of errors over the preceding 24 hours, divided by the sum of errors over the preceding 24 hours, multiplied by 100.
Trends graph
The Trends section provides a line graph that visualizes your integrations' and custom applications' API usage over time. The line graph consists of three lines:
- Green depicts successful requests (HTTP response codes between 200 and 399, inclusive).
- Red depicts responses that exceeded the rate limit (HTTP response code 429).
- Yellow depicts other application error responses (HTTP response codes between 400 and 499, inclusive, excluding 429).

Hover over a specific point on the graph to see the total request count. Specific HTTP response codes show for the yellow line. For more descriptive info on what these response codes mean, refer to the documentation on HTTP response status codes.
You can also filter the graph to show responses from applications authorized by specific admins or specific response codes by selecting the dropdown filters.
Use the time-picker to select the start/end date and time (UTC) for the graph and metrics table. The maximum selectable timespan is 30 days.

Metrics table

The Metrics section provides top usage metrics by:
- Applications, which might be custom applications/scripts or partner integrations.
- Operations, which are specific actions an application can take in the Dashboard API.
- Admins, whose API key the application uses.
- Source IPs, which are the source IP addresses from which the API requests originated.
Each tab summarizes the number of requests, successes, errors, success rate, and relative percentage of total requests that line comprises.
The status icons next to success rate indicate areas that potentially require attention:
- A red status icon signifies a failure rate of 80% and above. These applications warrant the most investigation and remediation.
- A yellow status icon signifies that 20–80% of the application's calls are succeeding. Optimize these applications to consume the API budget more efficiently.
- A green status icon signifies a success rate of 80% and above.
Download detailed logs (CSV export)
To dive deeper into the data, download the full request history logs. Download generates a CSV file with API consumption data for your own analysis. Common use cases include troubleshooting failed API requests, analyzing usage trends to optimize performance, auditing API access for suspicious activity, and debugging custom apps/scripts.
-
Make your data filter selections.
-
Select Download detailed logs at the top right of the page.

Only the most recent 100,000 requests are exported. If you believe the time interval you selected may contain more, reduce the interval. Data retrieval could take several minutes — do not refresh or exit the API analytics page while the download is in progress.
The CSV export contains the following data columns:
- Admin ID
- Admin Name
- Admin Email
- HTTP Method
- Host
- Path
- Query String
- User Agent
- Time stamp
- HTTP Response Code
- Source IP
- API Version
- Operation ID
Verification
Confirm that your API is working as expected:
-
A successful GET to https://api.meraki.com/api/v1/organizations returns response code 200 and a list of organizations for the API key in the authorization header.
-
A successful organization creation (POST) returns response code 201.
-
A successful administrator deletion (DELETE) returns response code 204 with an empty response body.
-
In API Analytics, a green status icon and a high percentage of successful requests confirm your application is performing well.
Troubleshooting
Status and error codes
Responses from the API generally use standard RFC 9110 HTTP Status Codes. Some examples:
- 400: Bad Request — You did something wrong, for example, a malformed request or missing parameter.
- 401: Unauthorized — Invalid API key.
- 403: Forbidden — You don't have permission to do that.
- 404: Not found — No such URL, or you don't have access to the API or organization at all.
- 429: Too Many Requests — You submitted more than ten calls in one second to an organization, triggering rate limiting. This also applies to API calls made across multiple organizations that trigger rate limiting for one of the organizations.
If the response code is not specific enough to determine the cause of the issue, the response includes error messages in JSON format, for example:
{ "errors": [ "VLANs are not enabled for this network" ] }
Read-only administrators can only make GET requests. Any other request results in 403: Forbidden.
Why API Analytics does not display 5xx error codes
API Analytics helps customers monitor their API requests and usage over time. The error codes displayed enable users to take actionable steps to troubleshoot and optimize their applications. Cisco has internal alerting and monitoring to resolve 5xx error codes, so displaying 5xx error codes is not actionable for the user.

