Skip to content

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. Because the refusal happens before the payload part, the rest of the body is not processed. On the service's own connection it stops accepting the body once at most a bounded remainder has been discarded (HTTP/1.1, Connection: close) or resets the request stream (HTTP/2); behind the edge proxy your connection to the edge is unaffected.

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 metadata or header part, then file).
  • 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

  1. Send only the parts the endpoint declares: the small JSON part first, then the file part carrying the payload.
  2. Fold any additional fields into the small JSON part instead of sending each as its own multipart part.
  3. 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.
  4. Retry normally. Behind the edge proxy your connection is unaffected; only a client that reaches the service directly over HTTP/1.1 sees Connection: close and should open a fresh connection, which most HTTP clients do transparently.

For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.