in case you’re still seeking for a solution, and assuming it’s about a REST API you’ve created in an Integration Server Instance: CORS settings are defined under “Settings” → “Extended”. A minimal configuration looks like this:
watt.server.cors.host=<your server’s address>
watt.server.cors.allowedOrigins=<your server’s URL>,<your application’s URL>
watt.server.cors.supportedHeaders=<request header>,<request header>,...
The server’s address is it’s hostname, and optionally a port number. The URLs include the scheme, hostname, and optionally a port number, but no
/path?query#fragment components. The request headers are specific headers sent from your application to the server’s REST API. A specific example configuration is:
You can identify the relevant parameter values when inspecting an OPTIONS request made by your browser on behalf of the application to the server. Use your browser’s developer tools for inspecting this. The desired host address can be found in the
Host header, the application’s URL can be identified in the
Origin header, and the request headers are defined in the
The result code 200 you’ve mentioned is maybe from such an OPTIONS request, and based on the response from the server your browser decided not the issue the actual API request at all.
More information on CORS configuration can be found in the Integration Server Administrator’s Guide:
Your setup is working in Postman because in that case CORS is irrelevant. There is no application with a separate origin in this case (you could pretend this by setting the
Origin header). CORS mechanisms are used by browsers when issuing cross-origin requests, which means that the browser requests a resource from a server located at some address on behalf of an application located at a different address.