It is a known issue, and a very long time one. ServiceAPI supresses the default host authentication (i.e. removing the authentication cookie from the request), which renders the Order Management (built on Web API) useless. Of course it's less than optimal, but the only way to work around this for now is to have ServiceAPI installed on a separate site. 

Aha, thanks that explains a lot. Hopefully this will be fixed eventually.. But when I looked into this with the knowledge from your reply I saw that this has been an issue since 2016 so I guess we will have to live with it for a while. Is there an easy way to "remove" this in a azure build or do we have to have two brances or repos ?

Thanks again

Good question, I don't know exactly how other customers do it, but technically you can just have another site (empty commerce + serviceapi) in your solution with a publish profile, pretty much like what you have commerce manager and cms/front end publish profiles 

We are now running into this problem as well. However, a separate site is not so easy since we are hosting on DXC. (Where a separate site is quite costly too)

Is there any other way to fix this, or is there any clarity on when this will be fixed?

It has been being discussed on and off for quite some time, but no decision has been made. 

Apparently there is another way.

You can add this code to a Initialization module. 
This will disable the suppression of cookie authenication, and thus make cookie authentication work for service api, so less secure when this is disabled.

var handler = GlobalConfiguration.Configuration.MessageHandlers
    .FirstOrDefault(x => x.GetType() == typeof(PassiveAuthenticationMessageHandler));
 
if (handler != null)
{
   GlobalConfiguration.Configuration.MessageHandlers.Remove(handler);
}

The code mark provided is the way to do it at the moment however it does open up the possibility of CSRF vunerability since you are now allowing authentication through both bearer token and cookies.

Discuss with your client to determine if this is acceptable.