Forward existing APIs with Auto Proxy

Auto Proxy can forward gateway traffic to an upstream API when no matching Cloudgate action exists. It can provision a forwarding workflow from the first unmatched request.

Configure upstreams#

Open Workflows → Auto Proxy. Review the enabled state and separate sandbox and production base URLs. Use absolute HTTP or HTTPS URLs for the intended service.

At least one valid upstream URL is required when enabling the feature. If you configure only one environment, do not assume the other environment automatically uses it.

The forwarding configuration uses the global PROXY_BASE_URL selector. Provisioned Request nodes combine that environment's base with the incoming controller and route segments.

Understand route behavior#

An existing matching action is resolved normally. For an unmatched route, enabled Auto Proxy can create the controller/action and a Request node that forwards the call upstream.

This is useful when introducing Cloudgate in front of an existing API. It also means unfamiliar incoming routes can become forwarding workflows, so review the upstream scope and intended gateway exposure before enabling it.

Verify a representative request#

1. Select a harmless upstream GET operation.
2. Call the corresponding sandbox gateway path.
3. Inspect the created or selected forwarding action.
4. Check the outbound URL, method, headers, input, and response.
5. Verify gateway and user authorization requirements for the exposed operation.

Do not assume that forwarding an endpoint automatically supplies every upstream credential or reproduces a custom client script. Inspect the actual request contract.

Evolve the workflow#

Once a forwarding action exists, you can review its draft and add validation, authorization, transformation, or observability as appropriate. Preserve the existing client contract while making the change.

Use HTTP Request nodes for explicit integrations and release review before changing live behavior.