agent hit HTTP 429 from the accounting API mid-invoice-pull and timed out retrying

TL;DR

A 429 mid-pull means the agent outran the API's quota; retrying immediately and often makes the quota window worse and the agent's own outer timeout kills the run first. Read the retry-after guidance when present, back off with growing delays and jitter, lower the agent's steady request rate, and checkpoint each batch of invoices so the pull resumes where it paused. The goal is a pull that slows down under pressure instead of dying under it.

agent hit HTTP 429 from the accounting API mid-invoice-pull and timed out retrying

Use this when

• Invoice pull logs show HTTP 429 responses beginning partway through the run.
• The agent's retries are immediate or fixed-interval and the run ends on its own timeout.
• Smaller pulls or off-peak pulls complete without 429s.

Not for this skill when

• 429 appears from the very first call with a message about quota for the day or a disabled key. That needs quota or account action, not backoff tuning.
• The API returns 403 rather than 429. Permissions, not pacing, are the problem.

Steps

1. Inspect the 429 responses for retry-after values and any quota headers, and note the request rate the agent was sustaining. Verify: the backoff design uses the provider's own signals
2. Add checkpointing per invoice batch, persisting pulled invoice ids before requesting the next batch. Verify: a killed run lists exactly the invoices already secured
3. Implement backoff on 429: wait the retry-after duration or an exponentially growing delay with jitter, and cap total wait per batch. Verify: logs show waits growing, not a retry storm
4. Reduce the steady-state request rate or batch size to sit under the observed quota. Verify: a sustained pull runs without triggering 429 at the new rate
5. Resume the interrupted pull from its checkpoint and tie the final invoice count and totals to the source system. Verify: the completed pull matches source counts with no duplicates from resumed batches

Variant phrasings

HTTP 429 accounting API invoice pull backoff retry after

The 429-during-pull phrasing.

agent timed out retrying rate limited API checkpoint

When adding resume checkpoints.

Compatibility: Accounting APIs such as QuickBooks, Xero, and NetSuite rate limits in agent integration jobs.

Why it happens

Rate limiting is the API protecting shared capacity, and 429 is a request to slow down delivered as an error. Agents that treat it as a failure to retry aggressively convert a pause signal into a self-inflicted denial of service against their own quota, and their outer timeout, set for normal work, expires during the storm. Providers publish retry-after precisely to coordinate the slowdown; honouring it is both the polite and the fastest route to completion.

Edge cases / pitfalls

• Daily quota 429s differ from per-minute throttles: the wait is until quota reset, and the job should park and report rather than back off for hours.
• Parallel workers multiply request rate; a shared rate limiter across workers prevents them from collectively breaching quota.
• If 429s arrive even at low rates, check for other integrations sharing the same app credentials and quota.

Provenance

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