## 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

```text
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

```text
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