A hotel group wants guest Wi-Fi sign-in hosted on its own web server so it can collect a room number and marketing consent. The MR access points will redirect each guest browser to the hotel portal, and after the check the guest must land back on the controller link so access is granted. Which step carries that return handoff in the external captive portal flow?
Select an answer to reveal the explanation.
Short Explanation
Your portal is only half the handshake: the controller supplies a grant URL for the guest’s browser to submit to. After you authenticate the guest, post the authorization to that URL so access is granted. Think of it as a claim ticket you hand back at pickup.
Full Explanation
Meraki’s external captive portal uses a redirect handshake, not a webhook or an API write from your server. When a guest browser reaches the splash setting, the access point redirects it to the portal URL you registered, appending query parameters that identify the client and provide the controller’s base_grant_url. Your page can capture the room number and marketing consent, then submit the authorization to that supplied grant URL; the controller authorizes the client and continues the browser to the requested destination. Posting the guest’s MAC address to a Meraki webhook does not grant access: webhooks are outbound notifications Meraki sends you, not an inbound channel for authorizing a client. A Meraki-hosted splash page is a different customization path and does not meet the requirement to collect form data on the hotel’s own server. Redirecting guests straight to the hotel landing page skips the controller’s grant URL, so the controller does not authorize the client. Exam caveat: focus on submitting to the supplied grant URL rather than memorizing parameter names. Practical check: test a sign-in and confirm the guest reaches the Internet without a second prompt.