Since the URL is only accessible if the request originates from our internal server IP, one option is to set up a reverse proxy on your internal network. This proxy would route the call on behalf of users outside your network. For example, if the API returns a URL like `www.abc.com`, you can rewrite it as `www.reverse.com` (the reverse proxy). When accessed, the reverse proxy will handle the request to the original site and return the result to the user.

Using an Intermediate Server (Gateway or Proxy)

Since the URL should be accessed from your internal server, you can set up an intermediate redirection mechanism. The general idea is to make your internal Gateway handle the redirection behind the scenes on the server, while the client simply interacts with a neutral page or URL.

Here’s how you can achieve it:

1. Server-Side Processing in Gateway:

   • When the client triggers the Gateway to call the external API, the Gateway will receive the URL from the external API response.
   • Instead of directly sending this URL back to the client, the Gateway could act as a proxy and fetch the content from the URL itself.

2. Return a Server-Accessible Link to the Client:

   • The Gateway, after retrieving the data from the external URL (internally, from the server), can respond back to the client with a server-generated link.
   • This could be a local URL hosted on your internal server, which your front-end app can safely redirect to.

Thank you Kerollos & Siya.

We started cracking our brain. We can achieve 1. Sever-sde Processing in Gateway with a REST GET call, and then extract the content. That is not an issue.

As for 2. Return a Server-Accessible Link, how do we host the internal page? Do we just create a new screen with a empty container and I guess we have to load it with the content we've got from 1. ? And how do we handle the interaction in the content?

We thought of iframe, but iframe likely don't handle the interaction well.