Skip to content

Multipart Part Too Large

URI: https://docs.ankatech.co/errors/multipart-part-too-large
HTTP Status: 413 Payload Too Large

When you see this

A non-payload part of a multipart request to one of the true-streaming endpoints exceeded the seam's byte cap of 2,097,152 bytes (2 MiB). The cap applies only to the small parts — metadata and header — never to the file part, which carries the payload and has no size limit at all. The refusal is raised after at most cap + 1 bytes of the offending part have been read, before the payload part is touched, and 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 JSON metadata or header part carries content that belongs in the payload — an inlined document, an embedded Base64 blob, a full certificate chain.
  • The payload was sent under the small part's field name instead of as the file part.
  • An unrecognised part name was used: any part the platform does not declare is read under the same cap, and its name is reported as <unrecognised> rather than echoed.

Response Example

{
  "type": "https://docs.ankatech.co/errors/multipart-part-too-large",
  "title": "Multipart Part Too Large",
  "status": 413,
  "detail": "The 'metadata' part exceeds the 2097152 byte limit for a non-payload part. Send the large content as the 'file' part, which has no size limit.",
  "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. Move the large content into the file part, which the streaming surface reads without an API size limit (a proxy in front of the deployment may cap uploads; see Behind a buffering proxy).
  2. Keep the small part to the descriptive JSON the endpoint declares.
  3. If the detail names <unrecognised>, the offending part is not one this platform declares — send it under the endpoint's own part name (metadata, header or file).
  4. Do not look for a setting to raise: the cap is a fixed constant in the streaming seam (StreamingMultipartReader.SMALL_PART_MAX_BYTES), deliberately not operator-configurable — it is a heap guard on an untrusted body, not payload-size policy.

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