When using an HTTP Caller, it also works. However, I need to explain a .Net Developer how to put together the API Call. He has the same problem as in the API interface of FME Server (see screenshot above).

So, this is fine: 

What makes this different from a call in the browser?

My first guess would be that the zip file gets corrupted because it's sent as a text file rather than as a binary file. The developer needs to check the content type of the file transfer.

Thank you David, I indeed saw that this is not part of his procedure.

However, the first screenshot of the API interface of FME Server states Content-Type: application/octet-stream

Why wouldn't this be working?

I couldn't say, but I guess it's theoretically possible that the header be right, but the actual file contents be wrong.

I suspect that the API documentation forms are auto-generated using something like Swagger, so I'm not sure how much testing it gets at Safe.

I transferred the zip file to fme server by using the following configurations:

Yes, within an FME process it worked well, but the API call comes from another application. The problem was solved. The developper answered me the following: 'I have passed the body in a different way (first pack everything in memory and then pass everything at once instead of streaming) and that seems to work. Of course, that approach has the disadvantage that those packets could theoretically be arbitrarily large and this could completely use up the application's memory.'