HTTP 400 on PDF input_file with JPEG 2000 images or an embedded C2PA manifest (gpt-5.4) + /Rotate pages still cropped

We run gpt-5.4 (gpt-5.4-2026-03-05, Responses API) inside a UiPath agent that sends documents as PDF input_file (base64). Over the last few days we’ve seen failures that look like a recent change in PDF ingestion.

1. HTTP 400 “Bad Request” on PDFs with JPEG 2000 images

  • Affected PDFs contain images with /Filter /JPXDecode. These are standard 8-bit sRGB or greyscale JP2 images and decode fine in MuPDF, PDFium and Pillow/OpenJPEG.
  • Seen with two different PDF producers (Power PDF Create, dbAutoTrack PDFWriter for .NET), on both image-only PDFs and PDFs with a text layer.
  • A/B test: replacing only the JPX image streams with Flate (identical decoded pixels, nothing else changed) makes the same request succeed. Reproducible.

2. HTTP 400 on a PDF generated by ChatGPT itself (embedded C2PA manifest)

  • A plain-text ReportLab PDF with no images. An OpenAI-signed C2PA manifest (“Content Credentials”, application/c2pa) is attached to it as an embedded file (/AF + /EmbeddedFiles).
  • A/B test: the same PDF, rewritten as a single revision with the manifest kept, fails with You uploaded an invalid file. Please try again with a different file. The original revision without the embedded manifest succeeds.
  • So the API rejects a PDF that ChatGPT itself produced and signed.
  • Retried using gpt-5.6-sol: same issue.

3. Still present: pages with /Rotate are cropped

  • Scanner PDFs (landscape MediaBox 842×595 + /Rotate 270): the model only sees a 595×595 square. The top ~29% of the upright page, where often important data sits, is missing. Same issue as this thread: 1378921 (id - can’t include links here)
  • Physically rotating the page image upright fixed it. Moving the rotation into the content stream (/Rotate 0 + a cm matrix) did not, in our tests.

Questions

  • Was PDF ingestion for input_file changed recently? Are JPEG 2000 images and embedded files (including C2PA) unsupported now?
  • Could the API return a descriptive error instead of a bare 400? The whole agent run fails without any hint of the cause.
  • Any update on the /Rotate fix?

As a workaround we’re adding a pre-processing step (probably a OCR model or: rotate pixels upright, re-encode JPX images, strip embedded files).

This exact failure mode is also happening to us. Our production org has ZDR enabled, and experiences the JPEG 2000 failure. Our dev org does not and continues to work with these kinds of PDFs.

Could it be related to recent Zero Data Retention changes?