A transit-agency integration catches HTTP 429 from the Meraki Dashboard API and immediately reissues the identical request in a tight loop. Why is that control flow wrong?
Select an answer to reveal the explanation.
Short Explanation
Slamming the counter bell the instant you are told to wait turns a soft ceiling into a self-inflicted outage. Back off on 429; do not spin.
Full Explanation
HTTP 429 signals the Meraki Dashboard API rate ceiling was hit. Immediately reissuing the identical request in a tight loop adds load exactly when the platform asked for less traffic, amplifying congestion and deepening the outage for every transit-agency integration sharing that quota. Correct control flow backs off—ideally honoring Retry-After or using exponential delay with jitter—inside a finite attempt budget.
Believing 429 always means the resource was permanently deleted confuses rate limiting with removal (typically 404) or other client errors. Requiring a switch to SOAP after any 429 invents a protocol mandate Meraki does not impose for throttling. Ignoring all 4xx and only handling 5xx discards actionable client-side signals including 429, 401, and 403.
Exam caveat: some APIs return 429 with rich quota headers; use them for pacing, but never interpret “slow down” as “retry as fast as possible.” Operational check: when catching 429 from Meraki, enforce a mandatory delay (Retry-After or backoff), cap attempts, and log remaining quota if present before the next Dashboard call. Pair the backoff with a maximum attempt count so a prolonged Meraki throttle becomes a visible transit-agency job failure instead of a silent CPU spin. If Retry-After is present, use it as the floor delay; if absent, grow delays exponentially before the next Dashboard attempt.