A retail chain scripts Meraki port changes for 120 stores with Python, needing secure calls, correct endpoint routing, and handling of busy-hour throttling. Which Dashboard API practice covers authentication, base URL and rate limits?
Select an answer to reveal the explanation.
Short Explanation
You can keep your calls secure and on track by using the API host, pacing requests, and honoring the server’s retry guidance. Your throttling stays manageable when you pause as requested.
Full Explanation
The correct practice combines the controls needed for the 120-store script: send the API key in a Bearer header, route requests to api.meraki.com, pace calls, and honor Retry-After when throttling occurs. Sending the Bearer key to api.meraki.com while using fixed delays has the right authentication and host, but a fixed schedule does not adapt to a busy-hour 429 response or the server’s indicated wait; it may retry too soon or waste time. Sending the Bearer key to dashboard.meraki.com and honoring Retry-After with pacing handles authentication and rate limits, but dashboard.meraki.com is the web Dashboard host, not the API host, so requests go to the wrong service. Sending the key in a Bearer header to api.meraki.com and honoring Retry-After, but skipping pacing, has the right authentication, host, and retry timing; however, relying only on retries after throttling can cause avoidable bursts and repeated 429 responses. Exam caveat: distinguish the Dashboard website hostname from the API hostname, and use the authentication method specified for the API version in the question rather than assuming all API-key header conventions are interchangeable. Practical check: inspect a test request’s URL and Authorization header, then verify that the client waits for Retry-After on 429 responses and limits its normal request rate.