Document upload via API fails with 'Unsupported Media Type' 415 error

We’re building a document ingestion pipeline for Agile 9.3.6 and consistently getting HTTP 415 ‘Unsupported Media Type’ when uploading PDF files via the document management API. The documentation says it supports PDF, but our POST requests are being rejected.

Request headers:


Content-Type: application/pdf
POST /api/v1/documents/{docId}/files

The API accepts the document metadata creation fine, but fails when we try to attach the actual file. We’ve tried various MIME type configurations and multipart form approaches without success. Has anyone successfully implemented PDF uploads through the doc-mgmt API? What’s the correct content type and request format?

The 415 Unsupported Media Type error you’re encountering is a common issue when working with Agile’s document upload API. The problem stems from misunderstanding how the API handles file uploads versus metadata. Here’s a comprehensive solution addressing all three critical aspects:

MIME Type Handling: Agile’s document API validates MIME types at two levels - the HTTP request Content-Type and the individual file part Content-Type in multipart uploads. Your original approach of setting Content-Type: application/pdf at the request level is incorrect for file uploads. The request-level Content-Type must be multipart/form-data with a boundary parameter. The PDF MIME type is specified within the multipart section for the file part itself.

Additionally, verify that application/pdf is registered in Agile’s allowed MIME types. This is configured server-side in Admin > Server Settings > File Manager. If PDF isn’t in the whitelist, the API will reject it regardless of correct formatting.

Multipart Form Data: The file upload endpoint requires properly structured multipart/form-data encoding. Here’s the correct format:


POST /api/v1/documents/{docId}/files
Content-Type: multipart/form-data; boundary=----Boundary123

------Boundary123
Content-Disposition: form-data; name="file"; filename="document.pdf"
Content-Type: application/pdf

[PDF binary content here]
------Boundary123--

The field name MUST be ‘file’ (lowercase). The filename parameter in Content-Disposition should include the .pdf extension, which Agile uses to validate against the declared Content-Type. The boundary string must be unique and match between the Content-Type header and the body delimiters.

File Upload API: The document creation and file attachment are two separate API operations:

  1. First, create the document object (POST /api/v1/documents) with metadata
  2. Then, attach the file using the document ID (POST /api/v1/documents/{docId}/files)

Don’t resend metadata in the file upload request - it’s already associated with the document ID. The file upload endpoint only expects the file part in the multipart form.

Common Implementation Issues:

  • Missing or incorrect boundary parameter in Content-Type header
  • Using ‘attachment’ or ‘document’ instead of ‘file’ as the field name
  • File extension mismatch with Content-Type (e.g., .doc file with application/pdf type)
  • Not including filename in Content-Disposition header
  • Attempting to upload file and metadata in a single request

Testing Approach: Use a tool like Postman or curl to verify your multipart structure before implementing in code. Most HTTP libraries have multipart helpers that handle boundary generation and formatting automatically - use those instead of manually constructing the multipart body. In Java, use Apache HttpClient’s MultipartEntityBuilder. In Python, use the ‘files’ parameter in requests library.

Once you switch to proper multipart/form-data encoding with the correct field name and MIME type configuration, your PDF uploads should work reliably.


This draft is based on general Oracle Agile PLM knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

The document upload API requires multipart/form-data encoding, not direct application/pdf. You can’t just POST the binary content with a PDF content type. You need to structure it as a multipart request with the file as one part and metadata as another. The Content-Type header for the overall request should be multipart/form-data with a boundary parameter.

“Tested this on Agile PLM 9.3.6 and setting the MIME type at the multipart file part level rather than the top-level HTTP request header resolved the 415 error immediately.”

Also check your Agile server’s MIME type configuration. The allowed file types are defined server-side in the Agile settings. Even if you send the correct multipart format, if PDF isn’t in the allowed MIME types list, you’ll get the 415 error. Admin can check this in Java Client under Admin > Server Settings > File Manager > Allowed File Types. Make sure application/pdf is listed there.

I’ve confirmed PDF is in the allowed file types list on the server. Now working on converting our request to multipart/form-data. Do I need to send the document metadata again in the file upload request, or is it just the file part? And what should the field name be for the file in the multipart form - ‘file’, ‘attachment’, or something else specific to Agile?

The field name should be ‘file’ in the multipart form. You don’t need to resend the document metadata - that’s already associated with the document ID in your URL path. Just send the file part with the correct filename in the Content-Disposition header. Make sure your multipart boundary is properly formatted and matches between the Content-Type header and the body separators.

I’ve implemented this successfully. One gotcha: the API is very particular about the Content-Disposition header format in the multipart section. You need to include both the field name and the filename parameter. If the filename extension doesn’t match the Content-Type you’re declaring, Agile will reject it. So if you’re uploading a PDF, make sure the filename ends with .pdf and the Content-Type for that part is application/pdf.