Is it possible to use the same domain for API Gateway and Static S3 bucket behind a Cloudfront distribution?

I'm currently creating a feedback app in AWS. I have the backend in Lambda which is connected to API Gateway and the frontend of it is served by a Static S3 bucket behind a Cloudfront distribution.

I would like to enable TLS 1.2 on the API Gateway, however, this only seems possible via Cloudfront. I also want to be able to serve it on the same domain name but a different path as the S3 bucket. Currently, the S3 bucket sits on feedback.domain.com. I did have a custom dodmain hooked up to the API Gateway on api.feedback.domain.com, which would work when I made requests to it via Postman. However, when I made requests via the JavaScript on the S3 bucket pages, it would never work and I'd get a CORS error. I am happy to use this if more viable but I would need to ask another question about CORS.

I would like to get the API Gateway to sit on feedback.domain.com/api, because as far as I know, using the same domain as the page making the request should overcome CORS. I've tried the below setup but cannot get this to work.

When I browse to feedback.domain.com/api, I get the error page I set up in Cloudfront. I've tried creating an invalidation so it has cleared the cache on the Cloudfront distribution, but this hasn't changed anything.

I modified the setup so the S3 bucket's origin path was /web/* however i then proceed to get AccessDenied errors everywhere
Setup:

Thank you in advance to anyone that can offer their wise wisdom

UPDATE:

Below are my Cloudwatch Logs for the API stage. I go to feedback.domain.com/api, get a 403 error with my custom error page defined in Cloudfront, but no log in Cloudwatch:

Here are behaviours:

API behaviour:

Current origin setup:

A note to @Caldazar, You mention 403 means I'm hitting the API, however, if I go to a none-valid url, feedback.domain.com/IDoNotExist I still get a 403 error. I believe this is something to do with S3?

The problem is in your Origin path.

The Origin path value is actually what will be appended to your request when it's sent to the origin. For example, a request to https://example.com/api/test would result in a request being sent to https://example.com/api/*/api/test

For API Gateway, your Origin path should be your API stage, for example /dev, /prod...

You should create additional behavior that would have Path pattern /api/* and Origin set to your API origin that you created above.

Since you would have /api/ in your path, this wouldn't be matched properly to the path you have in API Gateway. To deal with that, you should add a CloudFront Function to your API behavior created above as part of the Viewer request. CloudFront Functions are at the bottom of the Edit behavior page. This function should change /api to /. This is code that works for me for such situations:

function handler(event) {
    var request = event.request;
    var uri = request.uri;

    // Check whether the URI starts with "api"
    if (uri.startsWith('/api/')) {
        request.uri = uri.replace('/api/', '/');
    }

    return request;
}

Edit based on new details:

In order to hit the API, you cannot go to /api. You behaviour is set to forward to API Gateway only if your path is /api/* which means, only if you go to a URL like feedback.domain.com/api/mymethod.

As for the second part, S3 will return 403 code if a file does not exist, because there's a possibility that a file actually exists, but your user does not have permission to see the file.