Pinecone 400: invalid argument, usually oversize requests or bad params

TL;DR: 400 Invalid Argument means the request itself is malformed. The two big sub-causes are oversize upserts (about 2 MB per request) and bad parameter shapes (values not a flat list of numbers, id over 512 characters, metadata over 40 KB per record, more than 2048 non-zero sparse values, wrong types in filters). Shrink and reshape, do not retry. The 400 is deterministic: the same bytes fail the same way every time.

The error, verbatim:

400 Invalid Argument: Your request contains invalid parameters.

Steps:

1. Check the upsert size first. A single upsert request is capped at about 2 MB; tens of thousands of vectors in one call 400s. Split into batches that fit. Success: each batch is under the cap.
2. Check parameter shapes: values is a flat list of numbers, id under 512 characters, metadata under 40 KB per record, sparse values under 2048 non-zero. Success: every field is inside its limit.
3. Check filter types: comparing a string field with $gt, or passing a single value where $in needs a list, 400s. Success: filter shapes match the docs.
4. Validate client-side before sending: batch size, id length, metadata size, vector shape. Reproduce once, fix the bytes, resend. Success: 200.

When to use: Pinecone 400 Invalid Argument on upsert, query, or fetch.

When not to use: 429s (back off and retry), 5xx (retry), index-not-found (wrong index name), or dimension mismatches (different error).

Compatibility: Pinecone vector DB API, all SDKs.

Variants:

• pinecone 400 invalid argument
• pinecone upsert too large
• pinecone invalid parameters

Root cause: the bytes are wrong, not the timing. That is the whole diagnostic: client errors are deterministic, so the fix is always in the payload.

Edge cases:

• Trap: retrying a 400 with backoff. The error-handling guide says not to retry client errors (except 429). A 400 retry loop is a very expensive no-op.

Pinecone's error-handling guide defines 400 as invalid parameters and forbids retrying client errors. The upsert guide documents the request size cap; the limits reference documents 512-char IDs, 40 KB metadata, and 2048 sparse non-zero caps. Verified against live docs 2026-09-26.