Multipart Part Count Exceeded
URI: https://docs.ankatech.co/errors/multipart-part-count-exceeded
HTTP Status: 400 Bad Request
When you see this
A multipart request to one of the true-streaming endpoints carried more parts than the streaming seam admits. The reader counts parts as they arrive and refuses on the ninth: the cap is eight. No single entity is too large — every part may be a handful of bytes — so the refusal is a 400 on the envelope, not a 413 on a payload. The response carries Connection: close, because the refusal happens before the payload part and the connection would otherwise keep ingesting the rest of the body.
Common Causes
- The request carries more than eight multipart parts.
- A client library appends extra form fields alongside the two parts the endpoint declares (the small
metadataorheaderpart, thenfile). - A generated or proxied multipart envelope repeats parts, or adds boundary parts of its own.
Response Example
{
"type": "https://docs.ankatech.co/errors/multipart-part-count-exceeded",
"title": "Too Many Multipart Parts",
"status": 400,
"detail": "The request carries more than 8 multipart parts.",
"instance": "/api/v3/crypto/stream/encrypt",
"correlationId": "7c9e6679-7425-40de-944b-e07fc1f90ae7",
"timestamp": 1730000000
}
Content-Type: application/problem+json — the response follows RFC 9457 Problem Details.
How to Resolve
- Send only the parts the endpoint declares: the small JSON part first, then the
filepart carrying the payload. - Fold any additional fields into the small JSON part instead of sending each as its own multipart part.
- Do not look for a setting to raise: the cap is a fixed constant in the streaming seam (
StreamingMultipartReader.MAX_PART_COUNT), deliberately not operator-configurable — it bounds CPU and connection time on an untrusted body, and an operator who can widen a guard can remove it. - Reopen the connection before retrying: the refusal closes it.
For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.