Two city networks both broadcast a friendly name Guest. Automation must enable the Guest SSID on one network via Dashboard. What goes in the path segment {number}?
Select an answer to reveal the explanation.
Short Explanation
Friendly names can collide across networks—the API still addresses a numbered slot. GET the SSID list, find which number is Guest, then PUT that number.
Full Explanation
When two city networks both broadcast a friendly name Guest, the Dashboard wireless SSID URL still addresses a per-network numeric slot, not the broadcast string. The {number} path segment is the SSID slot index (commonly 0–14) learned from GET /networks/{networkId}/wireless/ssids for that specific networkId. Automation finds which numbered entry has name Guest on the target network, then PUTs that number—so cross-network name collisions never enter the path.
Putting the exact broadcast string Guest into {number} fails because the path key is the numeric slot index, not the SSID name operators see on phones. Generating a random UUID locally fails because Dashboard will not recognize a client-invented UUID as an SSID slot identifier on that resource. Duplicating the Meraki organization id into the SSID path fails resource addressing: organization id belongs in org-scoped discovery calls, not as the SSID {number} segment.
Exam caveat: slot numbering is per network; Guest might be slot 3 on one civic network and slot 7 on another even when the friendly names match exactly.
Operational check: GET ssids for the chosen networkId, filter where name equals Guest, assert exactly one match for that network, and PUT enabled true only to that returned number before validating client association.