## TL;DR
Thirteen months of statements is hundreds of API calls, and an unpaced agent hits the rate ceiling partway and loses the run. Read the API's stated limits, pace requests below them with a token bucket or simple delays, honour retry-after guidance on limit responses, and structure the fetch as thirteen independent monthly chunks with saved state, so a limit hit pauses one chunk instead of killing the year. History pulls are background work; design them to be slow and unstoppable.

```text
bank API rate limit hit mid-pull and the agent's 13-month statement fetch failed
```

## Use this when
- The fetch fails partway through a long history range with rate limit responses from the bank API.
- Recent short pulls succeed; only the long backfill fails.
- The agent retries immediately or in a tight loop when limited, worsening the block.

## Not for this skill when
- The API is returning server errors, not rate limits. Backoff still helps, but the cause is provider health.
- The account's plan or tier caps history at a shorter range. Then chunking cannot help; the data must come from statements or an upgraded tier.

## Steps
1. Capture the limit evidence: the response code, any retry-after value, and the API's documented limits for the endpoint. Verify: the pacing target comes from the provider's numbers
2. Restructure the fetch into per-month chunks, each saving its transactions and a completion marker before the next starts. Verify: a stopped run shows exactly which months are complete
3. Pace requests under the documented limit with delays or a bucket, and on a limit response wait the retry-after duration before resuming the current chunk. Verify: the agent's request rate stays under the ceiling in its logs
4. Run the 13-month fetch to completion in the background pattern, monitoring chunk markers rather than babysitting requests. Verify: all thirteen months carry completion markers
5. Tie the fetched history totals per month to the bank statements. Verify: each month's fetched total agrees with its statement, proving no chunk was silently truncated

## Variant phrasings
### bank API rate limit long history fetch backfill 429
The history-backfill phrasing.
### agent rate limited mid pull resumable chunks
When chunking the fetch.

Compatibility: Bank API rate limits for Plaid-style and direct bank APIs, and agent backfill job design.

## Why it happens
Rate limits are quotas over time, and backfills are bursts. An agent written for daily incremental pulls, a handful of calls, will naturally burst through a quota when asked for a year of history in a loop with no pacing. The API cannot distinguish an enthusiastic backfill from abuse, so it throttles both. Pacing aligns the agent's demand with the quota, and chunk state converts throttling from a fatal error into a pause.

## Edge cases / pitfalls
- Some providers offer a separate bulk or history endpoint with different limits. Check before pacing a chatty endpoint for hours.
- Retry-after values are instructions, not suggestions; ignoring them can escalate a throttle into a temporary block.
- Cache reference data such as accounts and categories across chunks; refetching them per chunk wastes quota the transactions need.

## Provenance

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