An engineer's script reads every network in an organization from the Meraki Dashboard API. It authenticates with a bearer token and calls the versioned base URL, but repeated runs start returning HTTP 429. Which request behavior keeps this integration within the Dashboard API rate limits?
Select an answer to reveal the explanation.
Short Explanation
Meraki applies rate limits per organization and per source IP, so backoff after a 429 is the fix you need—not more threads or extra keys. It behaves like one checkout lane: more shoppers do not open a second register.
Full Explanation
The Dashboard API accepts a bearer token in a request header when using the versioned base URL. Its rate limits include an organization-level limit and a source-IP limit, so splitting calls across API keys does not provide more organization-level headroom. When a request receives 429, honor the Retry-After header when present and use exponential backoff for retries. This spreads calls out and helps avoid immediately hitting the limit again. Pointing at the bare host omits the documented API version path, so it does not call the versioned API route. A large thread pool can create bursts that hit the rate limits sooner. Rate-limit figures can change, so consult current documentation rather than memorizing a number.