Thanks David Searle and Andrew Quinn for your help. So yes, I think the only way to get around this would be to have a proxy service, as you suggest Andrew Quinn. Having looked at the logs for Intapp, it seems like the response is received (the status is 200 and the response data appears to be valid) however I think its a limitation of the appliance not being able to handle anything that is not encoded as UTF-8.

Thanks for sharing your update David Searle. So I guess anyone in a similar situation, their only option right now would be to create some middleware service (i.e. AWS API Gateway/Lambda, or Azure equivalent) that proxies the request and performs the translation so that IntApp receives the required content response? With the content type translations being based somewhat around the common types.

Andrew Quinn , Mani Sodhi, - I took this investigation further and got Intapp and HighQ dev's on the line...

The outcome wasn't great I'm afraid and we reached a bit of an impasse. Here is a summary of what was concluded:

"Whilst they (HighQ Devs) accept that 'guessing' the file type based on the file name isn't ideal, it has been the design of the system since the start and this creates difficulties in overhauling it. The reason for this is because there isn't any de facto file type white-listing in collaborate. This means that, in effect, any file-type could be uploaded into the instance. So a historical decision was made that, anywhere in the system, when we are returning a content-type header, it will always be either 'octet-stream' or 'x-download', and then any operation needed to 'workout' what the file type actually is, will utilise filename in content-disposition, rather than content-type. 



They did accept that their chopping and changing between 'octet-stream' or 'x-download' is inconsistent and will be carrying out investigation into how they can improve this, (potentially changing the endpoints, so the choice between the two can be parameterised). 



Also Andy (Intapp Dev) was correct , the charset values isn't being appended client-side, its actually our web-servers which are adding this. Whilst the (HighQ) developers didn't elaborate on this, they did say they didn't think it was possible to change this. 



All of your observations have been taken on board and we have had long discussions internally, but I'm afraid as things stand, the work the (HighQ) developers would need to commit to change this, would be beyond what they would be willing to commit to, in its it scope. The developers were also keen to point out that they do have other 3rd parties who have written integrations using these endpoints, who would be adversely affected by a total overhaul of the current design..."

I lost interest in persuing things after this as it seemed that, even with the right heads in the room, there was not the flexibility required to move things forward.

I would really love it if Intapp and HighQ came together on this as they are, after all, two of the bigest players in the Law/FinTech market place and making this work would make sense for us all....

Andrew Quinn - yes, no luck on Intapp though. Seems like its a limitation on the product.

Mani Sodhi, so you added a User-Agent header and string to the headers tab? (see David's image above). Postman does this automatically in the "hidden" headers (PostmanRuntime/x.xx.x) so it naturally works as expected in Postman.