A nightly Python job collects wireless client counts for every Meraki network in a large retail organization. It runs behind a corporate egress proxy that forwards only standard Authorization headers, the API answers some bursts with HTTP 429, and the report must still contain every network. Which request pattern satisfies the proxy, throttling, and completeness requirements?
Select an answer to reveal the explanation.
Short Explanation
Your proxy only forwards the standard Authorization header, so send your OAuth access token as a Bearer token to https://api.meraki.com/api/v1. If the API returns 429, wait for the Retry-After time before retrying—like waiting your turn—so you’ll collect every network.
Full Explanation
The correct request pattern uses OAuth in the standard Authorization header, which the corporate proxy is specified to forward, and sends requests to the Meraki API base URL. When a request receives HTTP 429, honoring Retry-After follows the server's stated retry timing rather than guessing when capacity will be available. Retrying the affected request and continuing collection lets the job recover from transient throttling while still gathering the required results. The API-key approach is a common Meraki authentication pattern, and its retry behavior is appropriate, but its X-Cisco-Meraki-API-Key header is not among the headers this proxy forwards; the request may therefore fail before reaching the API. Bounded concurrency and exponential backoff are also standard ways to reduce load and recover from throttling, but that approach explicitly ignores Retry-After, so it does not respect the server-provided delay required here. Enumerating networks from just one response page can work for a small organization, and the authentication and retry handling are suitable, but a large organization's network inventory may span paginated responses. Omitting later pages leaves networks out of the report, violating completeness. Exam caveat: Meraki authentication methods and rate-limit behavior can vary by API and context, so follow the requirements given rather than assuming one credential method always applies. Practical check: test the proxy path with the intended Authorization header, then compare the collected network IDs against the fully paginated organization inventory and verify that 429 retries wait at least the indicated Retry-After interval.