plaid error: RATE_LIMIT_EXCEEDED on /transactions/sync polling
Paces Plaid transactions sync polling with cursor and backoff. Use for RATE_LIMIT_EXCEEDED on sync. Not for re-auth errors.
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
RATE_LIMIT_EXCEEDED on /transactions/syncSteps
- Back the poll interval off (and honor Retry-After) Expected: the 429s stop.
- Persist the sync cursor and send it on every poll Expected: each poll is incremental and cheap.
- Stop polling when the response says there are no more changes Expected: no wasted polls.
- Monitor poll volume per item Expected: you stay under quota.
When to use
- RATELIMITEXCEEDED on transactions sync
- The poller is too aggressive or cursorless
When not to use
- The item needs re-auth (that is ITEMLOGINREQUIRED, 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