413 payload_too_large on a Sume Format run: the 4 MiB body cap

413 payload_too_large on a Sume Format run means the request body is over 4 MiB. The docs give the fix in one line: shrink input and send media by URL instead of inlining it. The response carries details.limit_bytes so a client can read the cap instead of hard-coding it.

This follows the Create a run and Format API errors docs, read 2026-09-29.

Which 413 did I get?

Sume documents two different 413 codes on the create call, plus one look-alike that is not a 413 at all. Match on error.code, not on the status.

How do I shrink the body?

input is the JSON object your service hands to the run, and Sume publishes no field list for it, so the size is yours to control. Note that input alone is limited to 2 MiB, and a larger one is refused with a 400 before the 4 MiB body cap matters. Keep large binary content out of the JSON: pass image URLs in attachments (image_url, or an asset_id), and any media URL you put inside input shares the run's attachment budget. A run can carry up to 30 images, at up to 30 MB each.

Send a URL when the content already lives somewhere Sume can reach. A URL costs a few dozen bytes in the body, while an inlined blob counts against the cap in full. The docs also require that attachment URLs are publicly reachable; otherwise the create fails with 502 attachment_fetch_failed, which is your input to fix despite the status.

Measure before you send. The check below prints the byte count and stops when the file is over 4 MiB, which is 4194304 bytes.

size=$(wc -c < body.json)
if [ "$size" -gt 4194304 ]; then
  echo "body is $size bytes, over the 4 MiB cap" >&2
  exit 1
fi
curl -sS -X POST "https://api.sume.com/v1/formats/acme/live-commerce/runs" \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: order-8823-lc-v1" \
  -d @body.json

Why does my webhook handler crash on the biggest runs?

That is the third row. When the run receipt is over 1 MiB, the webhook envelope arrives with payload: null, error.code set to payload_too_large, and error.result_url saying where to fetch it. status still reports the run's real outcome. A handler that assumes payload is an object will throw on your largest runs, so branch on null and fetch the receipt from result_url.

The 4 MiB and the 1 MiB caps are different limits on different directions of traffic: one is your request to Sume, the other is Sume's delivery to you.

The same envelope also carries request_id, which is identical on every retry of the same run, so dedupe on it before you fetch the full receipt.

Should I retry a 413?

No. It is a 4xx on your input, so resending the same body returns the same answer. The docs note that a 4xx at create costs nothing, so a failed attempt does not bill. Fix the body first, then retry with the same Idempotency-Key: the key is released after a failed create.