rate limit error hit mid-audit when agent tried checking 2000 reports

TL;DR

The agent's request rate exceeded the expense API's limit mid-run. Add request pacing (a small delay between calls), exponential backoff with jitter on 429 responses, and use batch or list endpoints instead of one call per report.

Error

rate limit error hit mid-audit when agent tried checking 2000 reports

Steps

1. Read the 429 response headers for the limit and reset time. Expected: you know the allowed rate and when the window resets.
2. Add pacing: sleep briefly between API calls so the sustained rate stays under the limit. Expected: requests flow without 429s.
3. On a 429, back off exponentially with jitter and retry; never retry immediately in a tight loop. Expected: the agent recovers instead of hammering the limit.
4. Replace per-report detail calls with list or batch endpoints that return many reports per request. Expected: far fewer requests for the same coverage.
5. Track request counts per window in the agent so it throttles itself before the API does. Expected: the agent stays under the limit proactively.

When to use

• An agent gets 429s mid-audit on large volumes.
• The run was progressing fine before the limit hit.

When not to use

• The API rejects the credential (authentication issue, not rate limiting).
• A single request fails (debug that request, not the rate).

Tool compatibility

• Expensify, Concur, Ramp, Brex APIs; standard 429 handling.

Variant phrasings

429 too many requests during audit

The HTTP-level phrasing of the same limit.

API quota exceeded mid-run

The quota-flavored wording of the same problem.

Why it happens

Audit agents are bursty: they fire hundreds of requests as fast as possible. APIs protect themselves with per-minute or per-hour caps, and the burst trips the cap partway through the run.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_QS3p1xAPN4aGxspwNLDRNw