Outreach API rate limit kicked in and the agent's retry logic hammered it harder - exponential backoff was never...

TL;DR

Retrying a rate-limited API call immediately is the worst response: it burns the remaining budget and gets the key suspended. Implement exponential backoff with jitter - wait 1s, 2s, 4s, 8s between attempts, add random jitter, respect any Retry-After header, and give up to a queue after a fixed number of tries.

Outreach API rate limit kicked in and the agent's retry logic hammered it harder - exponential backoff was never implemented

Steps

1. Find the retry code: search the agent's Outreach client for any loop that re-sends on failure with a fixed short sleep or no sleep at all. That is the hammering.

Expected: you can point at the exact loop doing immediate retries.

1. Replace the fixed retry with exponential backoff: delay = base * 2^attempt, capped at a max (e.g. 60s), plus random jitter of up to 25 percent so multiple workers do not retry in sync.

Expected: retry traffic decays instead of staying flat or growing.

1. Honor the Retry-After header when Outreach sends one. The header value overrides the computed backoff for that attempt.

Expected: the client waits exactly as long as the API asked.

1. Set a max retry count (4 to 5 attempts is a sane default). After that, move the work item to a retry queue with a future timestamp instead of looping forever.

Expected: a persistent outage produces a visible backlog, not an infinite loop.

1. Add a circuit breaker: if more than a threshold of calls (e.g. 20) fail with 429 inside a sliding window, pause the whole Outreach sender for a cooldown period and alert.

Expected: one bad afternoon no longer risks API key suspension.

Use this when

• Outreach API calls return 429 or throttle errors
• Retry attempts are making the error rate worse, not better
• An API key got suspended after a polling or retry loop

Not for this skill when

• The failure is a 401 invalid_token (OAuth/scope problem, backoff will not fix it)
• The failure is a 422 on prospect create (validation problem, retrying is pointless)
• The throttle is on HubSpot or Salesforce (same pattern but different headers and limits)
• The loop is intentional polling with a sane interval (check salesloft 429 guidance instead)

Variant phrasings

• "Outreach API throttling, agent retry loop made it worse"
• "exponential backoff missing on Outreach rate limit retries"
• "agent's retry hammered the Outreach API and got the key suspended"

Why it happens

The retry was written as "try again until it works", which is correct for a transient network blip and catastrophic for a rate limit. A rate limit means the server is asking for less traffic; identical immediate retries are more traffic, so the throttle deepens and the API provider escalates from throttling to suspension. Backoff turns retries into a decaying trickle the server can absorb.

Edge cases

• Outreach may throttle specific endpoints (mailbox sending) rather than the whole API. Backoff per endpoint keeps unrelated calls flowing.
• A mailbox-level cap ("mailbox throttling limit exceeded") is a quota, not a rate limit. No backoff schedule will fix it; wait for the daily reset.
• Jitter matters more than it looks: ten parallel workers with identical backoff retry in lockstep and re-trigger the limit together.
• Log every backoff event with attempt number and wait time. Without that log you cannot tell backoff is working.

Provenance

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