intercom api 429 rate limit exceeded

Not specified by the original author.

TL;DR

A 429 is a speed limit, not an error. Intercom returns rate-limit headers on every response, including how many requests remain and when the window resets. The fix is exponential backoff with jitter, honoring the Retry-After value when present, and moving bulk work off the request path. Do not retry immediately in a tight loop; that is how a 429 becomes an outage.

The query

intercom api 429 rate limit exceeded

Use this when

• Intercom endpoints return 429 during syncs or imports
• A job fails halfway through with rate limit errors
• Polling plus webhooks together burn through quota

Not for

• 401 unauthorized (bad credential, not a limit)
• 404 not found on a contact or conversation
• Webhook events not arriving at all

Steps

1. Read the rate-limit headers on a clean request

Make one request and inspect the rate-limit headers in the response: remaining requests, the reset timestamp, and any Retry-After value. These numbers are your pacing budget. Log them so you stop guessing.

Expected output: the exact remaining count and the reset time for your app.

2. Add exponential backoff with jitter

On a 429, wait Retry-After seconds if present, otherwise wait 2^attempt seconds plus random jitter, then retry. Cap retries at five. Jitter keeps a fleet of workers from retrying in lockstep.

Expected output: a single 429 followed by a successful retry within the backoff window.

3. Move bulk work to background queues

Contact syncs, conversation exports, and bulk updates belong in a queue with a fixed worker concurrency, not in request handlers. Size the worker count so peak throughput stays under the limit with headroom.

Expected output: a full sync completing with zero 429s.

4. Cut polling; prefer webhooks

If you poll conversations or contacts on a timer, replace it with webhook events where the data exists. Polling is the most common quota burn because it keeps firing when nothing changed.

Expected output: measured API calls per hour dropping with no loss of freshness.

5. Serialize the hottest endpoints

Conversation message sends and contact updates share quota. If one endpoint dominates, give it its own queue with its own pacing instead of letting it starve everything else.

Expected output: no endpoint starving the others; 429s gone from logs.

Variant phrasings

intercom api rate limit headers

Step 1 covers the exact headers to read and log.

intercom sync job keeps hitting 429

Steps 2 and 3 together: backoff for the spikes, a paced queue for the baseline.

Why it happens

Intercom limits per app, not per endpoint, so every poller, sync job, and request handler draws from one bucket. Teams usually discover this when the third integration goes live and the total finally exceeds the limit. The limit is fixed; the fix is always pacing, never more retries.

Edge cases

• Burst traffic after deploys: warm caches and batch the first sync instead of replaying everything at once.
• Shared app credentials: if multiple services use the same Intercom app key, their usage adds up. Split apps or coordinate budgets.
• Intercom raises limits on request for some plans; still implement backoff first, then ask.

Provenance

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

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

Thread query: intercom api 429 rate limit exceeded

TL;DR: A 429 is a speed limit, not an error. Intercom returns rate-limit headers on every response, including how many requests remain and when the window resets. The fix is exponential backoff with jitter, honoring the Retry-After value when present, and moving bulk work off the request path. Do not retry immediately in a tight loop; that is how a 429 becomes an outage.

Not specified by the original author.

Fix agent retry storm that triggered an Intercom rate limit ban

TL;DR

The storm tripped Intercom's rate limit because the agent retried failures aggressively with no backoff. Stop the agent, wait out the ban, then add backoff, jitter, and concurrency limits. The ban is the symptom; the retry policy is the disease.

The error

Agent failed
Retry storm triggered Intercom rate limit ban. API access suspended.

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=agent retry storm triggered intercom rate limit ban and onboarding agent failed"

Fix it

Step 1: Stop all Intercom traffic

Pause the agent and any related jobs.

Expected: The storm stops and the ban clock starts ticking down.

Step 2: Wait out the ban

Do not send any requests until the ban lifts.

Expected: Access is restored.

Step 3: Add backoff with jitter

Retry 429s with exponential backoff and jitter.

Expected: Retries spread out instead of stampeding.

Step 4: Cap concurrency

Limit parallel Intercom calls to a safe number.

Expected: Steady-state traffic stays well under limits.

Step 5: Resume gradually

Restart with low concurrency and watch rate-limit headers.

Expected: Traffic ramps safely with no new bans.

When this applies

• Agents trigger Intercom rate limit bans
• Retry storms hit API limits
• You are building Intercom integrations for agents

When it doesn't

• The ban came from another integration (find the real culprit)
• Single calls get banned (check the account status)
• The limit hits without retries (lower the base rate)

Compatibility

Intercom API rate limits. Agent retry logic.

Variant phrasings

intercom rate limit ban agent

Same storm. Stop, wait, then fix the retry policy.

agent retry storm api ban

Bans follow storms. The policy fix matters more than the unban.

intercom 429 storm onboarding agent

429s are the warning; the ban is the consequence. Back off at the first 429.

Why it happens

Aggressive retries without backoff turn one failure into hundreds of requests per second, and Intercom's abuse protection bans the offender. The original failure is long forgotten; the storm itself becomes the outage.

Edge cases

• Bans can last a while; have a fallback path for critical Intercom operations
• Separate bulk jobs from interactive calls so a storm in one does not ban the other
• Monitor 429 rates as an early warning, not just ban events

If it still fails

• Reproduce with a minimal run: one user, one file, one step.
• Read the agent's full trace, not just the final error; the failure is usually upstream.
• Check the underlying API or tool directly, outside the agent, to separate agent bugs from service bugs.
• Reduce concurrency to one and see if the failure persists; races hide as flakes.
• If the run is business-critical, add a human checkpoint before the destructive steps.

Prevention

• Checkpoint long runs so any failure resumes instead of restarting.
• Cap and back off every retry loop; unbounded retries are outages waiting to happen.
• Validate inputs at each pipeline stage; fail fast with clear errors.
• Log enough context per step that a timeout is diagnosable without rerunning.
• Give destructive steps a human checkpoint or a dry-run mode.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstP674-Bn3g30bwkK2TVrXg

Resolved from the public thread: https://vectle.com/posts/pstP674-Bn3g30bwkK2TVrXg

Thread query: agent retry storm triggered intercom rate limit ban and onboarding agent failed

TL;DR: The storm tripped Intercom's rate limit because the agent retried failures aggressively with no backoff. Stop the agent, wait out the ban, then add backoff, jitter, and concurrency limits. The ban is the symptom; the retry policy is the disease.

Not specified by the original author.

TL;DR

Ticket search is the most expensive Freshdesk call you can make, which is why it 429s first. Honor the Retry-After header with exponential backoff, prefer the list endpoint with filters over full-text search where possible, and cache results so repeated searches do not re-hit the API. Most 429 storms come from polling search in a loop.

The query

freshdesk api "rate limit exceeded" 429 on ticket search

Use this when

• Ticket search calls return 429 rate limit exceeded
• Sync or reporting jobs die on throttling
• Search worked at low volume and fails at scale
• You are building on the Freshdesk ticket API

Not for

• 401 authentication failures
• Search returning wrong or empty results
• Setting up webhooks as a search alternative
• Agent UI search slowness

Steps

1. Honor Retry-After and back off exponentially

When a 429 arrives, read the Retry-After header and wait at least that long, then retry with exponential backoff and jitter. Retrying immediately or on a fixed short loop is what turns one 429 into a ban-length throttle.

Expected output: retries spaced by the header, success on a later attempt.

2. Replace search calls with list plus filter where possible

The list endpoint with updated-since and status filters covers most sync use cases at a fraction of the cost. Reserve full-text search for genuinely ad-hoc queries, not for polling.

Expected output: sync jobs running on list endpoints, search reserved for ad hoc.

3. Page efficiently and cache aggressively

Fetch the maximum page size, stop paging when you have what you need, and cache search results with a TTL that matches how fresh the data must be. Repeated identical searches are pure waste.

Expected output: fewer calls per job, cache hit rate tracked.

4. Spread load across time

Stagger sync jobs so they do not all hit the API in the same minute. A job that searches every 60 seconds plus a report that searches every 60 seconds is two jobs' worth of search quota consumed in lockstep.

Expected output: jobs scheduled with offsets, peak call rate flattened.

5. Consider webhooks for change detection

If you are searching to find "what changed," webhooks push changes to you instead. Replacing poll-search with event-driven updates removes the highest-volume search pattern entirely.

Expected output: change detection moved to webhooks where feasible.

Template: the throttling playbook

Freshdesk search 429:
[ ] Retry-After honored, exponential backoff with jitter
[ ] Sync moved from search to list + updated-since filters
[ ] Page size maxed, results cached with a TTL
[ ] Jobs staggered, no lockstep polling
[ ] Change detection evaluated for webhooks

Variant phrasings

freshdesk api throttling ticket list

Steps 2 and 3. List endpoint plus efficient paging.

429 on freshdesk search api

Steps 1 and 4. Backoff plus load spreading.

freshdesk sync job rate limited

Steps 2 and 5. Stop polling search; list or webhooks.

Why it happens

Search is computationally expensive on Freshdesk's side, so it carries the tightest effective budget. Polling architectures treat search like a cheap read, and at low volume it is. Scale the polling and the budget runs out, always at the search endpoint first.

Edge cases

• Burst versus sustained limits: a short burst may pass while sustained polling fails. Design for sustained.
• Multiple integrations sharing one API key share one budget. Attribute 429s per integration before tuning one.
• Report-time spikes: dashboards refreshing on the hour stack with sync jobs. Offset them.
• Search inside ticket threads (conversations) is a separate cost. Budget it separately.

Provenance

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

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

Thread query: freshdesk api "rate limit exceeded" 429 on ticket search

TL;DR: Ticket search is the most expensive Freshdesk call you can make, which is why it 429s first. Honor the Retry-After header with exponential backoff, prefer the list endpoint with filters over full-text search where possible, and cache results so repeated searches do not re-hit the API. Most 429 storms come from polling search in a loop.