According to HPE the issue occurs because the request sent to the server is with an IP address/machine name and does not contain the domain that you pointed to when you configured octane.
There's a known issue for us that Octane Swagger will fail if access it with direct IP or machine name and not domain.

I was able to get this to work in my environment, if you remember when you configured octane you had to select a domain (same one that is at the end of your octane login, mine is josh@octane.com for example) on mine for example I used ''octane.com'' it was not a ''real'' domain that existed but it was what I setup to configure octane in my dev environment. Since ALM octane is setup to work with a domain it does not like when you try to access the API's using just a machine name or an IP address.

Here is what I did, since ALM octane seems to want the URL in this format (OctaneServerName.domain) I went into my hosts file in windows on the machine I am using to access Octane (C:WindowsSystem32driversetchosts) then I created a line for my ALM octane server I put in this line 192.168.0.16 cent.octane.com ''cent'' is the name of my Octane machine and ''octane.com'' is the fake domain I created when I installed octane and 192.168.0.16 is the ip address for the octane machine that I was using to access octane before. This way when I access Octane I am using the following URL ''cent.octane:8080'' this makes octane ''happy'' since the url on the backend with the domain we pointed to matches what I am using when I access the client whereas before I was using 192.168.0.16:8080 which it did not like. Doing it this way makes it where I can access swagger using the same version on premise that you have.

It sounds like HP is eventually going to make it where it works either way but for right now this seems to be a good workaround to access the menu