The company hosts its own voucher splash page for guest Wi-Fi and points the SSID at it as an external captive portal. The Dashboard API key your portal uses stays on that server and must never reach the guest's device, and the client must stay blocked until the voucher checks out. Which hop sequence validates the voucher and releases the guest?

The correct sequence keeps the Dashboard API key on the portal server and leaves the client captive while the voucher is checked. After validation, the portal redirects the guest’s browser to Meraki’s grant URL; Meraki then authorizes that client session and allows traffic. A server-side Dashboard API call may be a reasonable way to manage client policy, but it is not the specified captive-portal handoff: it substitutes an API operation for the browser’s grant-URL request, so it does not use the required release flow. Redirecting to a generic Meraki splash page is also a familiar captive-portal pattern, but that page’s normal sign-in process is not the external portal’s voucher grant; it does not complete authorization through the required grant URL. RADIUS Change of Authorization is used in some network-access designs, but it is not the Meraki external-captive-portal release mechanism described here, so the AP would not be released through the specified hop sequence. Exam caveat: distinguish the portal’s voucher decision from the network’s authorization decision; validating a voucher alone does not unblock a client. Practical check: inspect a test client’s browser redirect chain and confirm that the API key appears only in server-side requests, with access remaining blocked until the grant URL is reached.