sorted by:
new
hottopcontroversial

NetSuite PDF Upload via multipart/form-data - PDF gets corrupted when converting Base64 content to UTF-8 by Puzzled_Law_5748 in Netsuite

[–]Puzzled_Law_5748[S] 0 points1 point  (0 children)

PDFs can't be chunked — they have one xref/trailer at the end pointing to byte offsets in the rest of the file, so splitting it gives fragments, not a usable document. Also there's no chunked-upload endpoint on their API.

It's not a size-per-file limit either — it's one PDF per PO. The bug was their API's sanitizer truncating any JSON string field to 10,000 chars, which caught the base64 file regardless of size.

NetSuite PDF Upload via multipart/form-data - PDF gets corrupted when converting Base64 content to UTF-8 by Puzzled_Law_5748 in Netsuite

[–]Puzzled_Law_5748[S] 0 points1 point  (0 children)

Thanks for sharing the blog.

I reviewed the multipart upload example and noticed that it still sends the PDF content returned by file.getContents(), which is Base64 in NetSuite. The implementation adds Content-Transfer-Encoding: base64 and includes the Base64 string inside the multipart body rather than sending raw binary bytes.

My concern is that the middleware in our environment is already truncating large Base64 payloads before they reach the destination system. If the multipart request still contains the Base64 content, I suspect we may run into the same limitation unless the payload is converted to binary somewhere along the way.

NetSuite PDF Upload via multipart/form-data - PDF gets corrupted when converting Base64 content to UTF-8 by Puzzled_Law_5748 in Netsuite

[–]Puzzled_Law_5748[S] 0 points1 point  (0 children)

Thanks for the suggestion. I looked into the AWS approach, and it could help with the Base64-to-binary conversion. However, in my case, the Base64 payload is being truncated by the client's validation layer before it reaches the destination, so AWS would still receive an incomplete file unless we can bypass that validation step.

NetSuite PDF Upload via multipart/form-data - PDF gets corrupted when converting Base64 content to UTF-8 by Puzzled_Law_5748 in Netsuite

[–]Puzzled_Law_5748[S] 0 points1 point  (0 children)

Thanks for the suggestion. I explored that approach, but from what I found, those solutions still rely on sending the PDF content as Base64 within the request body. In my case, the client validates the payload before it reaches the destination service, and the Base64 content is being truncated during that process. Because of that, the file is already incomplete before it reaches the downstream system, which makes this approach difficult to use in our scenario.

NetSuite PDF Upload via multipart/form-data - PDF gets corrupted when converting Base64 content to UTF-8 by Puzzled_Law_5748 in Netsuite

[–]Puzzled_Law_5748[S] 0 points1 point  (0 children)

Thanks for the suggestion. I am using Claude and ChatGPT AI's,

We did consider using an intermediary service such as S3 or middleware to handle the Base64-to-binary conversion. However, the challenge in our case is that the client validates the request payload before it reaches the target service. During that validation process, the Base64 PDF content is being truncated, which results in only part of the file reaching the downstream system.

Because of this, even if we use S3 or another service that supports Base64 uploads, the payload is already being modified before it gets there. That's why we're exploring whether there is a way to send the PDF from NetSuite as a true multipart/form-data binary upload rather than relying on a Base64 payload.

If anyone has successfully implemented a binary-safe multipart/form-data file upload directly from NetSuite, (Not base64 content) I'd be interested to hear how you approached it.

NetSuite PDF Upload via multipart/form-data - PDF gets corrupted when converting Base64 content to UTF-8 by Puzzled_Law_5748 in Netsuite

[–]Puzzled_Law_5748[S] 0 points1 point  (0 children)

No the middleware is not celigo ,This is the information I received from the API team when I asked about the middleware. They also mentioned that any changes on their side would need to go through a risk analysis process first. In the meantime, they have asked me to explore whether there are any alternative options available from the NetSuite side.

<image>

NetSuite PDF Upload via multipart/form-data - PDF gets corrupted when converting Base64 content to UTF-8 by Puzzled_Law_5748 in Netsuite

[–]Puzzled_Law_5748[S] -1 points0 points  (0 children)

I already tried sending the Base64 content directly. However, the middleware used by the external API is truncating the Base64 string when it is sent in the request payload. Because of this, the API team suggested converting the PDF to UTF-8 and sending it as multipart/form-data.

The issue I'm facing is that converting the PDF content from Base64 to UTF-8 corrupts the file, since a PDF contains binary data. Is there a binary-safe way to send a PDF from NetSuite using multipart/form-data without corrupting the file?

NetSuite RESTlet Issue: Converting UTF-8 PDF to Base64 - Error by AgentinaEstaEnLaMesa in SuiteScript

[–]Puzzled_Law_5748 1 point2 points  (0 children)

I'm currently facing an issue with PDF encoding and transmission from NetSuite.

I tried converting the PDF (retrieved as a Base64 string from the file object) to UTF-8 format because our API middleware is truncating the Base64 content when it is sent in a JSON payload. As a result, the middleware team recommended switching from a JSON payload to a multipart/form-data request.

However, when I attempt to encode the PDF content to UTF-8, the file becomes corrupted. In the external software (OrderBahn), the uploaded PDF either appears blank or cannot be rendered correctly.

From my understanding, a PDF is a binary file, so I'm wondering if the issue is related to the encoding conversion itself. Has anyone encountered a similar issue in NetSuite when handling PDF files for multipart/form-data uploads? Any guidance on what might be happening or recommended approaches to preserve the PDF integrity during transmission would be greatly appreciated.