## 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

```text
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