Skip to main content
When the Corti Assistant is embedded in a host application, all network traffic from the embedded app may be routed through a proxy controlled by the host application. The proxy sits between the client and the Corti backend services.
The Corti web app already proxies all third-party service traffic (analytics, feature flags) server-side through its own API routes. This means the proxy only needs to handle two types of traffic:
  1. HTTP requests to the Corti web app
  2. WebSocket connections to the Corti real-time backend

Upstream URLs

The proxy forwards traffic to two upstream services. The exact URLs depend on your region:
Use the URLs that match the region your Corti tenant is provisioned in. Contact support if you are unsure which region applies.

Choose a Proxy Mode

Configure your proxy in one of two ways. Use the same mode consistently for the iframe URL, HTTP routing, and WebSocket routing. For subpath deployments, /assistant is only an example. You can choose any external path prefix, such as /corti-assistant or /vendor/corti, as long as your proxy forwards HTTP requests with that prefix intact and sends the same value in Corti-Forwarded-Prefix.

HTTP Request Forwarding

All HTTP requests from the embedded app are forwarded to a single upstream — the Corti web app.

Proxy root (without path)

When Corti Assistant is hosted at the proxy root, forward the request path unchanged and do not set Corti-Forwarded-Prefix.
No path rewriting is needed. The proxy passes through the full request path, query string, method, and body unchanged.

Proxy subpath (with path)

If you host the embedded app under a subpath (for example https://proxy.example.com/assistant/), forward the public prefixed HTTP path to the Corti web app unchanged and set Corti-Forwarded-Prefix to the external base path.
Do not strip the subpath before forwarding HTTP requests to the Corti web app. The Corti Assistant runtime base path shim strips the prefix internally and rewrites response URLs so browser requests continue to stay under the public subpath.
X-Forwarded-Prefix is not the supported external contract for Corti Assistant subpath hosting. Use Corti-Forwarded-Prefix.

Required Headers

The proxy must set the following headers on every HTTP request forwarded to the Corti web app: If you host the embedded app under a subpath, also set:
Corti may translate these headers into standard X-Forwarded-* headers inside Corti-controlled infrastructure. Customer proxies should use the Corti-Forwarded-* headers documented here.
In production, set Corti-Forwarded-Host from a normalized or fixed proxy hostname. If your proxy runs behind another trusted load balancer, configure your proxy’s real IP handling before setting Corti-Forwarded-For.
Example — forwarding a request: Proxy root, without path:
Proxy subpath, with path:

Response Handling

Your proxy returns the upstream response to the client as-is. No modification of status codes, headers, or body is required in your proxy. For subpath deployments, the Corti web app runtime base path shim handles its own URL rewriting before the response reaches your proxy.

WebSocket Forwarding

The Corti Assistant uses WebSocket connections for real-time audio streaming and clinical sessions. The proxy must handle the HTTP Upgrade: websocket handshake and bidirectionally forward all WebSocket frames.

Routing

The Corti WebSocket backend expects the /audio-bridge/ path prefix. For proxy-root deployments, the public WebSocket path is forwarded unchanged:
The path and query string are preserved when forwarding. For example:
For subpath deployments, the public WebSocket path includes the same prefix as the iframe URL. Strip that prefix before forwarding to the WebSocket backend:
Corti-Forwarded-Prefix is used by the Corti web app. The WebSocket backend still expects /audio-bridge/* paths.

Connection Lifecycle

  1. Upgrade — When the proxy receives a request with Upgrade: websocket, it establishes a WebSocket connection to the appropriate upstream based on the path.
  2. Message forwarding — All messages (text and binary) are forwarded bidirectionally between the client and upstream. Messages sent by the client before the upstream connection is established should be buffered and flushed once the upstream is ready.
  3. Close — When either side closes the connection, the proxy closes the other side.
  4. Idle timeout — WebSocket connections can be long-lived. Set the idle timeout high enough to avoid dropping active audio sessions (recommended: at least 4 minutes).

Client-Side Configuration

HTTP requests do not require any client-side configuration. Because the embedded Assistant is loaded from the proxy URL (the iframe src points to the proxy), all HTTP requests from the app naturally route through the proxy. WebSocket connections, however, connect to a separate backend host by default. To route them through the proxy, the host application must set websocketBaseUrl using configureApp(). The host application sends configureApp() with the network.websocketBaseUrl property. For implementation details, see the PostMessage API or Window API documentation.
When websocketBaseUrl is set, the app sends WebSocket connections through the proxy. For proxy-root deployments, set websocketBaseUrl to the proxy origin:
The path and query string are preserved. This is what enables the proxy to route connections based on /audio-bridge/*. For subpath deployments, set websocketBaseUrl to the same public origin and subpath used by the iframe URL. The Corti Assistant runtime base path shim keeps same-origin WebSocket requests under that subpath, so your proxy can route them before stripping the prefix for the WebSocket backend.
Call configureApp() before the user starts an interaction. You can call it any time after the embedded app has loaded and the ready event has been received. The configuration persists for the duration of the session.

NGINX Example (Proxy Root)

A complete NGINX configuration for proxying the embedded Corti Assistant. Replace the upstream URLs with the values for your region.
This example listens on port 80 for simplicity. For production, add TLS termination (listen 443 ssl) and certificate paths.

NGINX Example (Subpath Hosting)

Example configuration for hosting the embedded app under /corti-assistant/. Replace every /corti-assistant occurrence with the external subpath you choose. This setup:
  • Serves all Assistant HTTP routes under /corti-assistant/*
  • Sends the prefixed HTTP path to the Corti web upstream unchanged
  • Routes WebSocket /corti-assistant/audio-bridge/* to the Corti WebSocket upstream after stripping the subpath prefix

Implementation Checklist

  • Forward all HTTP requests to the Corti web app upstream URL
  • Set Corti-Forwarded-For, Corti-Forwarded-Host, and Corti-Forwarded-Proto headers on HTTP requests to the Corti web app
  • If using subpath hosting, set Corti-Forwarded-Prefix and keep the public subpath prefix on HTTP requests to the Corti web app
  • Handle WebSocket Upgrade requests
  • Route /audio-bridge/* WebSocket connections to the Corti WebSocket backend
  • If using subpath hosting, strip the subpath prefix before matching/forwarding WebSocket /audio-bridge/* routes
  • Buffer client WebSocket messages until the upstream connection is established
  • Send the configureApp action from the host application with network.websocketBaseUrl set to the proxy URL