Meraki API Feature Request: Public API Endpoint for Splash Authorizati

[Icush]

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:

1. Their Entra account is disabled
2. Their Meraki splash session remains valid for up to 90 days
3. 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 this 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:

1. PUT /networks/{networkId}/clients/{clientId}/policy → devicePolicy: Blocked to force deauthentication
2. POST /networks/{networkId}/clients/{clientId}/deauthenticate to send an 802.11 deauth frame
3. 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)

[Philip D'Ath]

That is a well-written request, and it seems very reasonable.

Are you able to use conditional access policies to specify a more reasonable session length?
Not for this use case, but we often specify a session length of 1 day or 7 days across all Enra ID services and applications.  This limits how long a stolen session token is usable for.

[Icush]

I haven't been able to get them down to a smaller period yet.  This is all a big change from on prem radius to Entra based for them.  But on the plus side, no more radius certificates and closer to ready to move from Azure hybrid to plain Azure.  Baby steps...

[obrigg · Accepted solution]

Thanks for raising this request. I made sure the relevant team is aware of it.