@Edgar
I checked the logs and this is what I found
this is a request body you sent when the response is 200 and valid
"{\"FileName\":\"relatorio_Viveiros Europlantas Lda.pdf\",\"SaveFormat\":\"pdf\"}"
and this is when you get an error, well at least in the requests that are successfully pass to our service
"\"\\\"SaveFormat\\\": \\\"pdf\\\", \\\"FileName\\\": \\\"teste999.pdf\\\" }\""
request body is not a valid json object
Hi @yaroslaw.ekimov,
Thanks for digging into this — that confirms something, but I think it’s a separate issue from the one currently blocking me.
That malformed body (teste999.pdf) is from an earlier troubleshooting attempt, when I was testing Make.com’s native “Make an API Call” action for the Aspose connector. I’d noticed independently that this specific action seems to wrap the entire request body in an extra layer of JSON string escaping before sending it — so {"SaveFormat": "pdf", ...} arrives as a JSON-encoded string rather than a JSON object. Your log confirms that’s exactly what happened. Good to have it confirmed server-side, but I’ve since stopped using that action because of this.
The issue currently blocking me is different and separate: it’s the native “Save a File as” action (and also “Convert a File”), which doesn’t involve any hand-typed JSON — it uses Make’s own structured fields (Name, Format, FileName). That one doesn’t return any JSON parsing error at all — it just times out after ~40s with no response whatsoever (ModuleTimeoutError, no requestId, nothing in your logs to match against, since no response ever came back).
So to be clear, there seem to be two distinct problems:
Could you check the logs specifically for requests to relatorio_ViveirosEuroplantasLda.docx/saveAs (or /convert) around 2026-08-24 10:37 UTC — those are the ones that never got a response at all, which is the one I actually need resolved?
Thanks again for looking into this.
@Edgar
Thanks for clarifying, I looked more precisely at the requests, and what I found is the duration of conversion sometimes around 42-43 seconds at our end, so that’s why you got timeouts after 40 sec, it seems that you need to increase timeouts for that document.
Please share that document for analysis, you can send it via private message.
Hi @yaroslaw.ekimov,
That explains everything — thank you for digging into the actual duration! I’ll increase the timeout on my end (switching to a generic HTTP call with a configurable timeout, since the native Make.com connector action doesn’t expose that setting) and test again.
I’ll send you the document via private message now for your analysis, in case there’s something about it that makes conversion consistently land right around that 40s edge (worth understanding even if the timeout increase fixes it on my side).
Really appreciate the thorough investigation — this was a tricky one to pin down from the outside.
@Edgar
I can’t find anything document specific for that long conversion, but it’s a template document, you must populate data to it before you save it as pdf, right?
If so, do you have a lot of data? just a simple template the same you sent me take the same amount of time to convert?
Sorry — I’d only sent you the blank template earlier. Just sent the actual filled document (~320KB) via DM.
To answer: yes, it has real data (6-row risk table, a few paragraphs of text, 9-entry TOC). But I tested this same filled document through the direct /words/convert endpoint (no storage round-trip) via your Swagger UI, and it converted in under 1 second.
So it doesn’t seem to be document complexity — it seems specific to the storage-based flow (upload → updateFields → saveAs). Could the delay be in re-reading the file from storage after updateFields, rather than the conversion itself?
I just tried upload that file to the storage made a conversion and it is the same time as any regular conversion, also I tested upload->update->saveAs every time conversion is around 200ms. So the only thing is left it’s how make execute calls and what exactly they do, as it’s not us who developed that connector I don’t know what causes the issue.
Hi @yaroslaw.ekimov,
That’s really helpful, thank you — confirms it’s on Make’s side, not Aspose’s. I’ll report this to Make.com support directly and switch to bypassing their native connector with generic HTTP calls (which should work fine now, given how fast your direct tests were).
Appreciate all the time you put into this — really thorough investigation.