Dedicated protected-IP entry points for enterprise APIs
Coordinate partner allowlists, TLS identity and forwarding while preserving application authorization.
Contents of this article
When a dedicated entry point matters
Enterprise APIs may serve partners with fixed destination IPs, hostname allowlists or certificate checks. Confirm whether addresses can change, how clients resolve the endpoint and which protocol behaviors forwarding must preserve.
TLS termination affects integration
TLS termination at the edge or origin changes certificate setup and client-identity handling. Mutual TLS requires hop-by-hop verification; not every forwarding mode transparently preserves client certificate information.
Trust proxy metadata only from trusted senders
Confirm how client addresses are conveyed and parsed. Do not trust Internet-supplied HTTP forwarding headers unconditionally. Address metadata for custom TCP also needs explicit compatibility at both ends.
Test callbacks and error responses
Test valid calls, failed authentication, timeouts and retries with partners. Check status, signatures and log correlation. Stable network access does not replace object authorization or idempotent writes.
References
RFC 7239: Forwarded HTTP Extension
NGINX stream proxy documentation