A managed-service team writes a Python script that lists every MX and MS device across twelve customer organizations in Meraki Dashboard. The script must authenticate with an API key, call the documented endpoint, and stay under the per-organization request ceiling during a full inventory sweep. How should the script address, authenticate and throttle its Dashboard API calls?
Select an answer to reveal the explanation.
Short Explanation
Meraki wants three pieces lined up: the versioned base URL, an Authorization header, and patience when the API says slow down. A 429 is the Dashboard's bouncer holding the door, so you back off instead of hammering the same org. It's where scripts cut corners, and it's where a long sweep dies.
Full Explanation
Authentication, addressing and throttling are three separate controls on the Dashboard API, and your sweep needs all three at once. The versioned base URL sends every request to the current API generation, while the key travels in the Authorization header as a bearer credential so it never shows up in a URL that a log might capture. Rate limits are enforced per organization and the service signals a breach with HTTP 429, so the correct handling is to pause and back off before retrying. Hammering the endpoint in a tight loop satisfies authentication and addressing but gets the sweep throttled partway through, leaving an incomplete inventory. Sending your Dashboard password as basic credentials fails because the API expects an API key or bearer token rather than an interactive login, and it also hands over far more privilege than the job needs. Dropping the version segment from the base path fails the documented-endpoint requirement and returns errors before any inventory work begins. Exam caveat: the exact burst allowance has shifted across releases, so remember the 429 signal and the per-organization scope rather than a fixed number. Practical check: run the sweep against one lab org, log every response code, and confirm each 429 is followed by a delayed retry.