Common use case
Connect a process to a private API without publishing it
Give an integration a fixed local path to one private API without adding private routes to its runtime.
Short answer
Run wzctl beside the process and map one API IP and TCP port to 127.0.0.1. Keep the API's normal token or certificate authentication.
The problem
An external integration often leads teams to publish an internal API or establish broad network peering. Both choices expose more than one outbound API call needs.
Choose and scope the connection model
Create a pass for the API's exact IP and port, then supervise wzctl while the integration runs. Configure HTTPS clients to preserve the API hostname for TLS when necessary.
- 1Deploy a publisher that can reach the private API.
- 2Choose the publisher ID, exact API IP, destination port, TTL, and local port.
- 3Start wzctl under process supervision and wait for its 127.0.0.1 port.
- 4Call the local endpoint with the API's normal authentication and correct TLS server name.
Example access flow
Process
Integration worker with supervised wzctl
Local endpoint
https://127.0.0.1:18443Access-pass target
10.0.5.20:8443 (/32)Authorization boundary
One TCP API target; the API token controls operations
When this pattern fits
- A script or integration initiates requests to one internal TCP or HTTPS API.
- The consumer can use a local port and configure TLS when needed.
- The runtime should not receive private DNS or general network routes.
- The API already provides operation-level authentication and authorization.
Security boundary and limitations
- The pass carries TCP only. It is not a webhook receiver and provides no DNS, UDP, ICMP, or general routes.
- Using 127.0.0.1 can break hostname verification unless the client preserves the original TLS name, SNI, and certificate validation.
- WireZTNA cannot restrict URL paths or methods. The API must authorize every operation and data request.
Frequently asked questions
Can a process call a private API without private routes?+
Yes. wzctl can present one fixed API IP and TCP port on 127.0.0.1 for that process.
Can --target use the API hostname?+
Use the exact API IP. A bare IP becomes /32, and the access pass does not provide private hostname resolution.
Will HTTPS work through the local port?+
The TCP connection will work, but the client may need the original TLS server name and Host header for certificate validation.