## TL;DR

Plaid's /transactions/sync is rate limited: slow the poll loop, honor Retry-After, and use the cursor so each poll only fetches changes instead of re-polling everything.

## Error

```text
RATE_LIMIT_EXCEEDED on /transactions/sync
```

## Steps

1. Back the poll interval off (and honor Retry-After) Expected: the 429s stop.
2. Persist the sync cursor and send it on every poll Expected: each poll is incremental and cheap.
3. Stop polling when the response says there are no more changes Expected: no wasted polls.
4. Monitor poll volume per item Expected: you stay under quota.

## When to use

- RATE_LIMIT_EXCEEDED on transactions sync
- The poller is too aggressive or cursorless

## When not to use

- The item needs re-auth (that is ITEM_LOGIN_REQUIRED, not rate limit)
- A different endpoint is throttled (then pace that one)

## Tool compatibility

- Plaid transactions sync
- Bank data polling

## Variant phrasings

### plaid sync rate limit

Slow the poll, honor Retry-After, and always send the cursor.

### transactions sync 429

Same: incremental cursor polls, not full re-polls.

## Why it happens

Polling without a cursor re-fetches history every time, which burns quota fast. Agents often drop the cursor because the first poll works without it.

## Edge cases

- Plaid may return 429 with a longer backoff during high load; respect it
- Do not poll faster than the data changes

## Provenance

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