## TL;DR
"Ticket limit exceeded" on bulk import usually means one of two things: you are creating tickets faster than the API rate limit allows, or the account has a cap on total tickets. The fixes differ completely: rate limits need pacing with backoff, account caps need cleanup or a plan change. Identify which limit you hit before changing anything.

## The query

```text
zendesk "ticket limit exceeded" error on bulk ticket import
```

## Use this when

- Bulk ticket imports fail partway with limit errors
- Migration scripts die after a few thousand tickets
- The error appears at a consistent count every run
- You are planning a large import into Zendesk

## Not for

- 401 authentication failures
- 422 field validation errors on import
- Import file format problems
- Trigger or automation behavior during import

## Steps

### 1. Identify which limit fired

Check the response headers and body for rate-limit signals versus account-limit language. Rate limits reset on a timer; account caps do not. This distinction decides the entire fix.

Expected output: the limit type named: rate limit or account cap.

### 2. For rate limits: pace the import with backoff

Batch in small groups, sleep between batches, and honor Retry-After headers with exponential backoff. Parallel workers multiply your effective rate, so throttle worker count before batch size.

Expected output: import proceeds without 429s at a sustainable pace.

### 3. For account caps: check current usage and clean up

Look at total ticket count versus the plan cap. Archive or delete test and junk tickets, close stale solved tickets per retention policy, and only then consider a plan change. Most "caps" during migration are test data from earlier runs.

Expected output: usage under cap, or a documented need for a higher tier.

### 4. Use bulk and import-oriented endpoints

Batch create endpoints and import modes (which can suppress notifications and side effects) exist for exactly this job. Creating tickets one at a time through the standard endpoint is the slowest and most limit-prone path.

Expected output: import running on the bulk or import path.

### 5. Checkpoint and resume instead of restarting

Record the last successfully imported record. On any limit error, stop, wait, and resume from the checkpoint. Restarting from zero re-imports successes and burns quota twice.

Expected output: resumable import with a durable checkpoint.

## Template: the import runbook

```text
Bulk import limits:
[ ] Limit type identified (rate limit vs account cap)
[ ] Batch size set, sleep between batches, Retry-After honored
[ ] Account usage checked; test/junk tickets cleaned
[ ] Bulk/import endpoint in use, notifications suppressed
[ ] Checkpoint written per batch; resume from last success
```

## Variant phrasings

### zendesk bulk import rate limit

Steps 1 and 2. Identify, then pace.

### zendesk account ticket limit reached

Step 3. Usage audit before anything else.

### migration hitting ticket limits

Full sequence as the migration runbook.

## Why it happens

Imports concentrate months of normal ticket creation into minutes, which collides with limits designed for human-paced traffic. Rate limits protect the platform; account caps are a billing boundary. Both fire during imports because imports are the one workload shaped nothing like normal use.

## Edge cases

- Side effects multiply cost: each import ticket can fire triggers, webhooks, and notifications that consume their own quotas. Suppress them during import.
- Suspended or archived tickets still count: deleting from the UI often archives. Check what counts toward the cap.
- Incremental syncs after the big import need pacing too. The import pace is not the steady-state pace.
- Parallel import workers: coordinate them on a shared rate budget or they will each assume the full budget is theirs.

## Provenance

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