Bug: multipart/form-data requests sent from Apidog Web are missing the boundary parameter

system · September 4, 2025, 12:25am

Hi team!

When sending a multipart/form-data POST request that includes a file using the Apidog Web client, the boundary parameter is missing from the auto-generated Content-Type header. This results in a malformed request that servers cannot parse, leading to a server-side exception and a 500 Internal Server Error.

Environment

API Client: Apidog (Web Version, we have our documentation hosted on Apidog.)

Browser: Google Chrome, zen (I didn't test other browsers, but pretty sure most of them are same behavior)

Server Framework: Spring Boot

Expected Result

Apidog Web should automatically generate a valid Content-Type header that includes a unique boundary parameter.

Example:

Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

The server should successfully parse this request and process the file upload.

Actual Result

The "Actual Request" view in Apidog confirms that the Content-Type header is sent incorrectly, without any boundary:

Content-Type: multipart/form-data

The receiving server throws a parsing exception. In our case, the Java Spring server log shows:
Java

org.apache.tomcat.util.http.fileupload.FileUploadException: the request was rejected because no multipart boundary was found

The client receives a 500 Internal Server Error in response due to the server’s inability to parse the request.

system · September 4, 2025, 12:53am

Hi Hojin Yang,

The web version doesn’t automatically generate the request header. Could you try downloading the Apidog client and use it instead?

system · September 4, 2025, 12:58am

in apidog client, I know it works.

This bug is pretty critical since we are planning to provide api documentation to our customer.

Obviously, client will try to send api request by apidog web version…

system · September 4, 2025, 4:07am

Hi Hojin Yang,

Thank you for your feedback. I’ve forwarded this issue to our technical team, and we’ll work on optimizing the logic for this part.

system · September 4, 2025, 5:12am

Thanks.

Let me know when you guys fixed this problem.

system · September 4, 2025, 5:43am

Hi Hojin Yang,

From our end, we couldn’t reproduce the issue. Did you manually add a content-type Header instead of using the auto-generated one? Please try sending the request without your manual added header.

system · September 4, 2025, 6:00am

Nope, actually what I did was sending api request in apidog web itself. After request has not been processed, I checked actual request section in apidog, and figured out this problem.

this is the apidog actual request that failed:

curl --location --request POST 'https://blah/api/v1/parsing/test' \
--header 'User-Agent: Apidog/1.0.0 (https://apidog.com)' \
--header 'Content-Type: multipart/form-data' \
--header 'Authorization: Bearer demo_api' \
--header 'Accept: */*' \
--header 'Host: test_url' \
--header 'Connection: keep-alive' \
--form 'file=@"cmMtdXBsb2FkLTE3NTY5NjU0NTgwNzItNw==/데이터 패브릭 리서치 가이드.pdf"'

I did mask host and api key, but other than that, everything is completely same with apidog actual request.

system · September 4, 2025, 6:01am

I really need this feature work since our customer will try-out api in documentation hosted by apidog…

system · September 4, 2025, 10:23am

Could you try using the “No Proxy” option in your docs site setting and try to send it in your docs site? Please refer to the documentation Request proxy in shared docs - Apidog Docs for instructions.

system · September 4, 2025, 11:32am

After setting no proxy option in your docs, request has been rejected due to cors issue…

system · September 9, 2025, 6:59pm

Just sent email including our hosted apidog documentation to [email protected]

system · September 9, 2025, 11:32pm

I’m facing the same issue on the documentation website. It happened when the new UI was incoporated. Can the team please take a look. We are able to send API calls from the apidog app and the api responds but from web documentation its giving 400 bad requet.

system · September 9, 2025, 11:33pm

The request body type of multipart-form-data

system · September 9, 2025, 11:35pm

system · September 9, 2025, 11:36pm

check the log on backend in case of sending the request from documentation website to an endpoint whose request body is multipart/form-data

system · September 15, 2025, 12:38pm

Hello, we’ve identified from our support team that this issue is related to the mediaType in the API definition. Could you let us know if this API was created through import or manually added? This will help us reproduce and resolve the issue completely.

system · September 15, 2025, 1:10pm

It was taken on import of API spec