## TL;DR

Eight hundred parallel-ish image downloads trip the API's rate limit fast. Cap concurrency (a handful of simultaneous downloads), pace requests, back off on 429s, and checkpoint completed downloads so a limit hit resumes instead of restarting.

## Error

```text
rate limit error hit mid-receipt-fetch when agent tried downloading 800 images
```

## Steps

1. Cap download concurrency to a small number (for example, 4 simultaneous). Expected: the request rate drops below the limit.
2. Add a short delay between download starts. Expected: the sustained rate stays smooth instead of bursty.
3. On a 429, pause downloads, wait out the retry interval from the response headers, then resume. Expected: the run survives the limit instead of failing.
4. Checkpoint each completed download to disk with its receipt ID. Expected: a resume point; completed images are never re-downloaded.
5. On restart, skip checkpointed images and continue with the rest. Expected: the run completes the remaining images only.

## When to use

- Bulk receipt-image downloads hit rate limits mid-run.
- Restarting re-downloads everything and hits the limit again.

## When not to use

- A single image fails to download (check that receipt's attachment).
- The API credentials are rejected (authentication issue).

## Tool compatibility

- Expensify, Concur, Ramp attachment download APIs; custom agent fetchers.

## Variant phrasings

### 429 during bulk receipt download

The HTTP-level phrasing of the same limit.

### Image fetch throttled mid-run

The throttling-flavored wording.

## Why it happens

Image downloads are the heaviest API calls in an audit run, and fetching hundreds of them as fast as possible looks like abuse to rate limiters. Pacing plus checkpoints turns the burst into a steady, resumable stream.

## Provenance

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