A coffee shop chain offers free Wi-Fi on Meraki MR with a branded loyalty portal that must capture email before granting four-hour access and track repeat visits. The portal is hosted externally and must enforce auth per client. Which External Captive Portal API flow grants the required access?
Select an answer to reveal the explanation.
Short Explanation
You can turn free Wi-Fi into loyal visits by collecting the email before access is granted. The splash authorization call then authorizes that client’s MAC for four hours.
Full Explanation
The required flow redirects each client to the externally hosted portal with Meraki’s grant parameters, captures the email there, and then calls Meraki splash authorization for that client’s MAC with a four-hour access duration. This makes authorization per client and ensures the loyalty email is captured before the client gets online; the portal can use that email to associate repeat visits. RADIUS authentication and accounting with a four-hour timeout can record sessions, but it is a different authentication architecture from the Meraki External Captive Portal API flow requested here. Calling splash authorization before collecting the email reverses the required sequence and can let the client online without completing the loyalty capture. A 24-hour MAC authorization with visit logging has the right general per-client approach, but it does not meet the required four-hour duration. Exam caveat: the portal’s visit history and Meraki’s access grant are separate functions, so granting access alone does not reliably track repeat visits by email. Practical check: test new and returning clients, confirm the portal records the email before authorization, verify the authorized MAC and four-hour duration in the dashboard or API response, and ensure repeat visits match the same loyalty record.