Too many items requested for the BatchGetItem call

TL;DR — BatchGetItem retrieves at most 100 items per call (and ≤16 MB of data). You requested more than 100 keys, so DynamoDB rejected the request. Split your keys into chunks of 100 or fewer and issue one BatchGetItem per chunk.

What it means

ValidationException: 1 validation error detected: Value at 'RequestItems.<table-name>.member.Keys' failed to satisfy constraint: Member must have length less than or equal to 100

# on DynamoDB Local the same call is rejected with a shorter sentence:
ValidationException: Too many items requested for the BatchGetItem call

BatchGetItem fetches items by primary key across one or more tables, but a single call is capped at 100 keys and 16 MB of returned data. Request more than 100 and DynamoDB rejects the whole call. Even within the limit, a response may return fewer items than asked (the 16 MB ceiling), reporting the rest in UnprocessedKeys. The over-limit case is an HTTP 400 ValidationException, not retryable until resized.

Why it happens

Requesting a large key set in one call — passing hundreds of keys straight into BatchGetItem.
A chunk bound above 100 — batching by count but using the 25-item BatchWrite limit's sibling incorrectly, or an off-by-one letting 101 through.
Counting tables, not keys — the 100 limit is total keys across all tables in the request.
Not paging UnprocessedKeys — assuming one call returns everything, so you never chunk.

How to fix it

Chunk keys into groups of ≤100 and send one BatchGetItem per chunk.
Handle UnprocessedKeys — retry any returned keys with exponential backoff; this happens even inside a valid 100-key batch when the 16 MB cap is hit.
Keep responses under 16 MB — with large items, request fewer than 100 per call.
Know what your SDK does for you — the low-level clients and the JavaScript document client do not split an oversized key list; you must chunk to 100 yourself. Some higher-level clients (the Java SDK's Enhanced Client and v1 DynamoDBMapper) at least retry unprocessed items automatically.
De-duplicate keys before chunking. Duplicate keys in one batch fail separately — dedupe first, then chunk.

Reproduce it

A BatchGetItem asking for 101 keys, one past the cap:

const Keys = Array.from({length: 101}, (_, i) => ({pk: {S: `K#${i}`}, sk: {S: 'META'}}));
await client.send(new BatchGetItemCommand({RequestItems: {orders: {Keys}}}));

Real output:

ValidationException: Too many items requested for the BatchGetItem call
HTTP 400

This one fails fast on the request shape — no partial read happens, and nothing lands in UnprocessedKeys. That is the difference between exceeding the 100-key limit and exceeding the 16 MB response limit, which does return partial results.

From DynoTable

Batch-read fewer than 100 keys at a time in DynoTable while you debug — open the table with ⌘K, filter to your key set, and confirm items exist before you wire chunked BatchGetItem in code. The item size calculator helps pick a safe chunk size when items are large.

Use the Query Builder to prototype single-key reads first. Switch profiles with ⌘P; Test Connection on Settings → Profiles. See Connect to AWS and Install.

Sources

BatchGetItem — Amazon DynamoDB API Reference (verified 2026-07-13)
Quotas in Amazon DynamoDB (verified 2026-07-13)

Too many items requested for the BatchWriteItem call — the write-side limit (25 items).
Provided list of item keys contains duplicates — the same key twice in one BatchGetItem.
ProvisionedThroughputExceededException — throttling that surfaces as UnprocessedKeys.
Code example: BatchGetItem in Node.js · in Python (boto3) — chunked reads with UnprocessedKeys retry.
Learn: DynamoDB batch operations

References

Last verified 2026-07-13 against the official AWS documentation linked above.

Reproduced 2026-07-26 against DynamoDB Local 2.x with AWS SDK for JavaScript v3.1095.0 — the output above is verbatim.