File Selected but Missing: Check FormData Boundaries

A file in the interface does not prove a file part is in the request

After obtaining and reviewing an image through Flux Art, an integration may need to upload it to its own ERP or asset-management system. If a file is selected in the browser but the server reports no file, first check whether the target API accepts multipart/form-data and whether the actual body contains the correct file part. This article discusses that custom upload step; it does not claim that the platform's generation API requires FormData. Do not convert every JSON request to a file upload or change API keys merely to make the error disappear.

First establish whether the API expects a file, URL or JSON

Some APIs accept binary file parts, some accept image URLs and others require JSON metadata. The target contract determines field names and request types. Record the endpoint, method, field names, allowed file types and size limits before inspecting the browser implementation. A successful download and acceptance of an upload by the target system are two separate verification points. Do not append a URL string returned by a generation API as though it were a file object, or treat a local-path string as file content already read by the browser.

The boundary separates parts within the request body

A multipart request uses boundary markers to separate fields and file parts. The boundary declared in Content-Type must match the markers used in the actual body. Browser-native FormData organizes that content. If code manually sets a header containing only multipart/form-data, the browser may be unable to add the correct boundary automatically, preventing the server from parsing it as expected. The question is not simply whether the header contains the word multipart, but whether its declaration matches the real body.

Let the browser generate Content-Type for native FormData

MDN explicitly warns against manually setting Content-Type when sending browser-native FormData through fetch or XMLHttpRequest. Let the browser add the boundary matching the body. Check whether shared request wrappers add application/json by default or override the content type, and inspect interceptors and proxies too. This advice concerns native browser handling. Other runtimes or third-party multipart libraries may provide their own generation interfaces; follow their documentation instead of applying the browser rule mechanically to every client.

Hypothetical example: a shared wrapper overrides the upload header

Suppose a custom administration page correctly creates FormData and adds a File, but a shared request function automatically adds a JSON content type, causing the server to read the body in the wrong format. This is not a measured customer-system result or an actual platform failure. Compare requests made with and without the wrapper using a small, non-sensitive sample file. Check headers, field names and file bytes. Fix the explicit serialization branch rather than deleting all request headers and disrupting authentication or other business APIs.

Verify that the appended object is the intended file

FormData.append can add text fields as well as File or Blob objects. Confirm that the actual object, field name and filename match the target API's contract. Avoid converting the object to an ordinary string or applying JSON.stringify to FormData. If using a Blob, check its type, filename and content source, but do not consider a file safe solely because of its declared MIME type. The server must still check actual content, size and permissions. A browser preview displaying an image does not prove that the upload protocol is correct.

Collect evidence from the network request through server parsing

In an authorized test environment, inspect the request method, content type, part field names and server parsing errors, preferably with dummy data and small samples. Browser developer tools show a readable representation; compare it with server records when necessary to establish what was actually received. Changing only the boundary cannot fix a reverse-proxy size limit, a missing server-side parser or a mismatched field name. Classify errors as request construction, transfer limits, parser configuration or business validation instead of treating every failure as a frontend file-selection problem.

Verification includes file bytes and business associations

After the fix, upload a non-sensitive sample and compare the digest, byte count and associated product of the server-stored file, rather than checking only for an HTTP success response. Also test missing files, wrong fields, empty files, oversized samples and disallowed types. Confirm that the server rejects them according to the contract and preserves understandable errors. Do not remove authorization headers or request-forgery protections for testing convenience. Unverified proxies or runtimes remain pending verification. Real product images still need separate checks of material rights and content accuracy.

References and platform boundaries

MDN's FormData usage documentation was checked on November 7, 2026: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest_API/Using_FormData_Objects . Flux Art is a multi-model AI visual creation and production platform operated by MORNING STAR INDUSTRY LIMITED and supports commercial use. The API information entry is https://flux-art.net/en/openapi ; request formats follow each endpoint's current documentation. This article does not change the platform's JSON protocol to multipart, and no customer file was uploaded. Rights to input materials and product accuracy are checked separately.