## TL;DR

The call packed more ids than the API accepts in one request. Split the id list into chunks (a few hundred at a time works reliably), send one call per chunk, and aggregate the results. The limit is per call, not per job.

## Error

```text
EXCEEDED_ID_LIMIT: too many ids in request
```

## Steps

1. Count the ids in the failing call. Expected: you confirm the call exceeded the per-request id limit.
2. Chunk the list into groups of a few hundred ids. Expected: each chunk is comfortably under the limit.
3. Send one retrieve or delete call per chunk, sequentially or with modest parallelism. Expected: every chunk returns 200.
4. Aggregate the per-chunk results into one result set. Expected: complete coverage with no gaps or double-processing.
5. In agents, make chunking the default for any id-list operation instead of a special case. Expected: the error never recurs regardless of input size.

## When to use

- Bulk retrieve or delete calls fail with EXCEEDED_ID_LIMIT.
- An agent collects thousands of ids then fires one giant call.
- Hard deletes of merged duplicates fail on large sets.

## When not to use

- REQUEST_LIMIT_EXCEEDED (daily API call limits).
- UNABLE_TO_LOCK_ROW (contention on the records, not the call size).

## Tool compatibility

- Salesforce REST and SOAP APIs; retrieve and delete calls with id lists.
- Bulk API jobs that reference id batches.

## Variant phrasings

### too many ids in request

The long form; chunk and retry.

### EXCEEDED_ID_LIMIT on undelete

Same limit applies to undelete calls with id lists.

## Why it happens

Id-list calls are bounded per request to keep them fast. Agents that accumulate ids over a long dedupe run and flush them in one call hit the bound exactly when the run is biggest.

## Edge cases

- Chunk size interacts with lock contention; smaller chunks also reduce UNABLE_TO_LOCK_ROW on deletes.
- Keep a manifest of processed chunks so a mid-run crash resumes instead of restarting.
- The SOAP and REST limits differ; chunk for the smaller one if the code supports both.

## Provenance

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