Meraki API Feature Request: Public API Endpoint for Splash Authorizati

Icush · ‎05-15-2026

Summary

Expose the existing revoke_splash_auth dashboard functionality as a documented, supported endpoint in the Meraki public API (api.meraki.com/api/v1).

Current Behavior

The Meraki dashboard provides a Revoke button on the client detail page for any client authenticated via splash — including Microsoft Entra ID (open-enhanced), Sponsored Guest, and Click-through splash types. This button works correctly and immediately invalidates the server-side splash authorization record for that client.

The underlying dashboard call is:

POST /manage/usage/revoke_splash_authBody: id={clientId}&auth_reason={splash_type}&ng_type=wireless&vap={ssid_number}

This endpoint requires an active dashboard browser session and a per-session CSRF token. It is not accessible via API key or OAuth2 credentials and is not documented.

The existing public API endpoint PUT /networks/{networkId}/clients/{clientId}/splashAuthorizationStatus with isAuthorized: false does not work for Microsoft Entra ID splash (open-enhanced) or Sponsored Guest splash. It returns:

400: "SSIDs X do not have Click-through splash enabled. No changes were made."

This means there is currently no public API method to revoke splash authorization for the two most commonly deployed enterprise splash types.

Requested Behavior

Add a public API endpoint:

POST /networks/{networkId}/clients/{clientId}/revokeAuthorization

Or extend the existing endpoint:

PUT /networks/{networkId}/clients/{clientId}/splashAuthorizationStatus

To support all splash types, including:

Microsoft Entra ID (open-enhanced)
Sponsored Guest
Click-through (already supported)
Any future splash/identity types

The endpoint should accept the same API key and OAuth2 credentials used throughout the rest of the v1 API.

Business Justification

Security and Compliance

Enterprise customers using Microsoft Entra ID splash for identity-based WiFi access need the ability to revoke WiFi authorization as part of automated offboarding workflows. When an employee is terminated or suspended:

Their Entra account is disabled
Their Meraki splash session remains valid for up to 90 days
The device retains full network access despite the account being disabled

This represents a security gap that cannot be closed through the public API. Customers managing CMMC, SOC 2, ISO 27001, or similar compliance frameworks require the ability to demonstrate immediate access revocation upon termination — a 90-day residual access window is not acceptable in these environments.

Automation Gap

The Meraki public API is otherwise well-suited for automated offboarding:

Client lookup by MAC/user: ✓ available
Client policy block (devicePolicy: Blocked): ✓ available
Client deauthentication: ✓ available
Splash session revocation for Entra ID / Sponsored Guest: ✗ not available

This single missing endpoint forces customers to choose between:

Maintaining a fragile browser-session-based automation against an undocumented internal endpoint
Accepting that terminated employees retain WiFi access for up to 90 days
Manually revoking sessions through the dashboard during every offboarding event

Customer Impact

Any organization using IPS-CORP-style Entra ID splash SSIDs for employee WiFi authentication faces this gap. As Entra ID splash adoption grows — driven by Meraki's own positioning of this feature as the modern enterprise authentication method — the number of affected customers will increase significantly.

Proposed API Specification

Endpoint

POST /networks/{networkId}/clients/{clientId}/revokeAuthorization

Request

json

{}

No body required — revoke all splash authorizations for this client on this network.

Optional scoping:

json

{
  "ssids": [2, 5]
}

Revoke only specific SSIDs.

Response

json

{
  "clientId": "abc123",
  "networkId": "L_123456789",
  "revokedAt": "2026-05-15T14:32:00Z",
  "ssidsRevoked": [2]
}

Error Responses

404 — client not found
400 — no active splash authorization to revoke
403 — insufficient API key scope

Workaround Currently in Use

To close this gap without the API endpoint, the current workaround requires:

PUT /networks/{networkId}/clients/{clientId}/policy → devicePolicy: Blocked to force deauthentication
POST /networks/{networkId}/clients/{clientId}/deauthenticate to send an 802.11 deauth frame
Accepting that the splash session remains valid and the device will reconnect without re-authentication once unblocked

This is operationally workable but not a security control — a determined user on a managed device could circumvent the MAC block, and the splash session itself is never invalidated.

References

Meraki API: PUT /networks/{networkId}/clients/{clientId}/splashAuthorizationStatus
Meraki API: PUT /networks/{networkId}/clients/{clientId}/policy
Meraki API: POST /networks/{networkId}/clients/{clientId}/deauthenticate
Meraki Dashboard: Client detail → Splash → Revoke button (functional, session-authenticated only)