403’s get generated client-side, so the calls from the other apps must be reaching your Mendix app, and your Mendix-app must be generating the 403-message before it reaches your published-Rest-service’s microflow. That means some processing of the Mendix-cloud between receiving the call and passing it to your microflow. That area is where the request handler is being the guard.

So a bit of doc-browsing brings us these two links:

Additional information about request handlers is available in the Requests section of Monitoring Mendix Runtime and the Applying Access Restrictions to Unnecessary Request Handlers section of How To Implement Best Practices for App Security.

Do the subjects in those articles bring you any closer to the solution?

Hi Colin,

Do you have an error handler setup on the Call REST action?

You can use this to potentially capture why the REST call is failing, depending on the level of detail the target REST API returns in the response.

Here’s a sample of one I have setup on one of my app projects.

Thanks for the comment, but I obviously didn’t explain my scenario properly.

I don’t get the error when calling a REST API; the error is when another service calls my app to an endpoint I am exposing. Postman is fine, so doesn’t help diagnose the problem

I know this is an old question but I don't see any accepted answers. In my case the 403's were generated by Mendix due to parallel incoming calls (by itself a perfectly normal thing to happen for a REST API). The error was that a microflow was not execute 'as it does not allow concurrent execution'. I found this message in the app log, but that was probably only because I have TRACE level logging enabled for REST Publish.

In my case the problem wasn't the REST handling microflow itself that had the 'disallow concurrent access' enabled, but a 'downstream' one that I called from the REST handling microflow.