## TL;DR
Stop pulling harder and start pulling smarter. A nightly job that pages through all tickets at full speed will hit Zendesk rate limits, especially when other integrations share the same account limits, and a job with no backoff dies mid-sweep leaving the churn signal half loaded. Read the limit headers, slow to a sustainable rate with proper retry behaviour, switch to incremental export where you can, and the sweep finishes every night instead of most nights.

```text
Zendesk API 429 too many requests during nightly ticket pull: churn signal sweep incomplete
```

## Use this when
- Zendesk returns 429 responses during the nightly pull and the job aborts or skips ticket ranges
- The failure happens at a similar point each night, often after other integrations have run
- CS reports ticket based churn signals missing for the same dates the pull failed

## Not for this skill when
- Zendesk status shows an incident during the window, making the 429s a symptom rather than the cause
- The job fails with authentication errors, which present differently and need the API identity checked first

## Steps
1. Instrument the pull before changing it. Log the response headers that carry the rate limit and remaining count, the retry guidance header when present, and which page or time window each 429 occurred in, across one full night. You need to know whether you hit the per minute limit, a concurrent request limit, or a shared account ceiling consumed by other tools. Verify: one nights limit pattern is captured with the specific limit type identified
2. Inventory everything else calling the Zendesk API on the same account. Reporting tools, QA scrapers, and a second integration often share the ceiling, and the nightly pull inherits whatever they leave. Coordinate schedules so heavy jobs do not overlap, and give the churn sweep a protected window agreed with the other owners. Verify: the inventory of API consumers and their schedules is written down with overlaps resolved
3. Implement correct retry behaviour. On a 429, wait for the interval Zendesk asks for in its response guidance, then resume from the exact page or cursor that failed, never from the start. Add a small jitter to waits so multiple workers do not retry in lockstep, and cap total retries so a genuine outage fails the run loudly instead of looping until morning. Verify: a throttled test run resumes mid-pull and completes without restarting from page one
4. Reduce the volume the job needs. Switch the nightly pull to Zendesk incremental export keyed on ticket update time, keeping a small overlap window to catch late updates, and request only the fields the churn signal uses instead of full ticket bodies with every comment for every ticket. Store the incremental cursor only after a run fully succeeds. Verify: the incremental pull processes a fraction of the old volume in a test run with matching ticket counts for the overlap window
5. Reconcile completeness nightly. Count tickets updated in Zendesk for the window against tickets loaded into your store, accounting for the overlap, and alert when the sweep loads materially fewer than expected, so a throttled or partial night is visible the next morning instead of surfacing weeks later as a missing churn pattern. Verify: the reconciliation count runs and an intentionally truncated test load triggers the alert
6. Backfill the known bad nights from Zendesk using the same incremental mechanism in small dated slices during the protected window, then re-run the churn signal detection for those dates so tickets that arrived during the broken period are scored like any other ticket. Verify: the bad nights are backfilled and their churn signals are generated

## Why it happens
Zendesk protects the platform with layered rate limits per account and per endpoint family. A naive full pull grows with ticket volume until it reliably crosses those limits, and without backoff logic the first 429 becomes a failed or partial run. Because the job is nightly and the failure is partial, gaps accumulate invisibly in exactly the historical ticket data that churn analysis depends on.

Compatibility: Zendesk API rate limits and incremental ticket export, in current Zendesk API versions, with scheduled integration jobs and shared account limits.

## Variants and edge cases
### Zendesk API 429 nightly export incomplete
['The nightly phrasing. Incremental export plus honoured retry timing solves the pattern, while simply starting the job earlier only moves the collision.']

### Zendesk rate limit retry after header handling
['The implementation variant. The wait Zendesk returns is authoritative, guessing a fixed sleep either wastes the window or retries too early and extends the penalty feel.']

### ticket pull missing tickets churn sweep Zendesk
['The completeness variant. Build reconciliation counts into the job, because a pull that finishes quietly with half the tickets is worse than one that fails loudly.']

Edge cases to work through before you close the incident:
- Search and export endpoints have their own limits distinct from core ticket endpoints. Know which family your job uses before quoting a limit number to anyone.
- Deleting or anonymising tickets for privacy compliance changes historical counts. Reconciliation should compare against Zendesks count for the same filters, not against last months totals.
- Keep API identities separated per integration where Zendesk allows it, so one runaway tool can be identified and paused without blinding the churn sweep.

## Provenance

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