Set the request content-type to "application/octet-stream" and check whether same content-type is allowed in webserver (supported) mime-types.

Hi Johnny,

There's a few things to say here:

1. "the text to binary does not seem to work for the text parts" - it's a System Action, and it works. I've never seen it fail. But it's binary data, so it doesn't display in the debugger;
2. You have used a manual "Boundary--" boundary. I'd advise against this, just leave the Boundary parameter of MultipartFormDataCreate empty, and use the returned BoundaryUsed;
3. You call ContentTypeGet as an Action, but you don't use the result. You also don't need this Action/Function, as MultipartFormDataCreate already returns the ContenType to use (as you've already done, I see);
4. Although HTTP-headers should be case-insentive, I'd set the "Name in Request" parameter of SignRequest to "Content-Type", as that's the correct spelling (though again, "content-type" should work);
5. You shared a Module that contains a Bearer token. You should really not do that. Although bearer tokens are only valid for a short time, a malicious person could use it to steal or destroy information.

Unfortunatly, none of these things will help you with your problem. So for trouble shooting, please increase the logging level of the REST service (in Service Center) and check whether the header parameters are set correctly, especially the Content-Type (the body can't be viewed since it's binary).

Thanx for your reply.

1. This is in the current context of the issue: when using textToBinary instead of 'Content' I keep getting the message that there is no content. So USING the TextToBinary does not seem to work.

2. I removed the "Boundary--"

3. There is more 'old' code in there (like I stated about the TextTobinary actions).

4. Like you said: it should work and I have never seen otherwise, but I changed it to proper casing.

5. The Bearer token is not valid so there is no issue there.

The stack trace with all logging levels up does not give me much more detail:

POST https://localhost.outsystemsenterprise.com/Stiply_IS/serviceapi/CreateSignRequest HTTP/1.1
Content-Length: 95
Content-Type: application/json
Content-Language: en-US
Authorization: Bearer xxx
Host: localhost.outsystemsenterprise.com
User-Agent: OutSystemsPlatform
OS-Host: localhost.outsystemsenterprise.com
OS-Path: /Stiply_IS
OS-Pta: /serviceapi
OS-Page: /CreateSignRequest
{"requestKey”:”xxx”,”inputParameters":{"DocumentarchiefId":9}}


HTTP/1.1 200 OK
Server: Microsoft-IIS/10.0
Content-Type: application/json; charset=utf-8
Authorization: Bearer xxx
{"outputParameters":{"Success":false}}

Thanks Kilian,

Adding the "application/octet-stream" does not make a difference. In fact I read one of your comments in a similar post which you advice against this suggestion made by someone else (??).

I did find the solution: adding '.pdf' to the name of the file as I discovered this was not part of the file name.

So, now it works without defining the content-type manually.

Thanks for your help!