TL;DR: You are calling a Textract API faster than your account's per-operation TPS quota allows. Slow the batch down (fewer concurrent jobs), add exponential backoff with jitter on this exact exception, and request a quota increase in Service Quotas if the workload legitimately needs more. The exception is retriable - do not treat it as a failed document.

```text
ProvisionedThroughputExceededException
```

1. Identify which call is throttling (StartDocumentTextDetection, GetDocumentAnalysis, etc.) from your logs.
   Expected: one operation accounts for most exceptions - that is the quota you are hitting.
2. Cut concurrency for that operation to 1-2 in flight and re-run the batch.
   Expected: exceptions stop; jobs complete slower but steadily.
3. Wrap the call in retry logic that catches ProvisionedThroughputExceededException with exponential backoff and jitter.
   Expected: occasional throttles self-heal instead of failing the batch.
4. If the throttled pace cannot meet your deadline, open Service Quotas, find Textract, and request an increase for the throttled operation in your region.
   Expected: AWS approves a higher TPS (often within a day); re-run at the new pace.

## Use this when
- batch Textract jobs fail partway with ProvisionedThroughputExceededException
- the same code works on small batches but dies on large ones
- you just parallelized the pipeline and throttling started

## Not for this skill when
- the error is InvalidParameterException or UnsupportedDocumentException - that is a document problem, not a quota problem
- you hit the concurrent-jobs limit (different error, different fix: poll and space out job starts)
- the throttling comes from your own downstream database, not Textract

## Variant phrasings
### textract ProvisionedThroughputExceededException batch
### aws textract throttling too many requests
### textract StartDocumentAnalysis rate exceeded

## Why it happens
Textract quotas are transactions-per-second per API operation, per region, per account. A batch loop that fires dozens of start calls at once blows past the default TPS in seconds. The service throttles instead of queueing, so unthrottled clients see failures, not delays.

## Edge cases
- Sync (AnalyzeDocument) and async (Start*) operations have separate quotas - tune each.
- Polling GetDocumentAnalysis too aggressively throttles the poller, not the starter.
- Quota increases are per region; a us-east-1 increase does nothing for eu-west-1.
- Backoff without jitter can synchronize retries into the next throttle wave; always jitter.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_mxVeNCI-_tTyv0eMmRHZkQ