Skip to main content
Your platform runs a WebSocket proxy that sits between the end user and Decart for the control plane (signaling, prompts, session events). Media (video and audio) flows directly between the end user and Decart over WebRTC — your proxy never touches it. This gives you a white-labeled experience with full media quality and visibility into all control messages.

When to use this path

  • Your platform already runs WebSocket infrastructure
  • You want full visibility into the control plane (prompts, images, session events)
  • You want white-labeled endpoints — end users never see Decart
If your platform is HTTP-native and you’d prefer not to run stateful WebSocket connections, see HTTP Signaling — same quality, same white-label, but with stateless HTTP proxy instead.

Characteristics

Media quality is identical to using Decart directly. Your WS proxy only handles signaling — video and audio flow peer-to-peer.

Reference implementation

ws-signaling-proxy

A complete working proxy in ~200 lines of TypeScript — message buffering, close-code sanitization, structured logging, and an e2e test.

Architecture

How it works

1

End user connects to your WebSocket endpoint

The end user connects to your platform’s WS URL — they never see a Decart endpoint.
2

Your proxy opens a connection to Decart

Authenticate with Decart using your platform API key and forward the model selection.
Your proxy connects to Decart with your API key.
3

Forward messages bidirectionally

Pump JSON messages between the client and Decart. Every message has a type field. You can log, validate, or modify messages as they pass through — see the message reference for the full protocol.
4

WebRTC connects directly

When the end user’s browser receives the SDP answer and ICE candidates through your proxy, it establishes a direct WebRTC connection to Decart via the IP:port in the ICE candidates. Your proxy is not involved in media.
5

Handle disconnects gracefully

When either side disconnects, close the other connection. Your proxy should handle both directions:

Message reference

Your proxy forwards JSON messages between the client and Decart. Every message has a type field that identifies it.
Messages your proxy receives from the client and forwards to Decart.
The sdp field is a string containing the full SDP (same format as RTCSessionDescription.sdp). Forward as-is.
Forward as-is. The candidate format matches RTCIceCandidate.toJSON()usernameFragment is optional and may be present depending on the browser. Signal end-of-candidates by sending null:
You can validate, filter, or replace this message before forwarding.
You can validate or reject this message before forwarding.
Reference images must be under 10 MB (decoded). Oversized images are rejected by the server.

Moderation

Prompts and images are moderated server-side before being applied to the model. Your proxy sees the result as acknowledgment messages:
  • Prompt acceptedprompt_ack with success: true
  • Prompt rejectedprompt_ack with success: false and an error string
  • Image acceptedset_image_ack with success: true
  • Image rejectedset_image_ack with success: false and an error string
Rejected content is not applied — the model continues with the previous prompt or image. Your proxy can add its own moderation layer before forwarding messages to Decart.

Usage tracking

Track usage by watching the generation lifecycle messages:

Proxy example

A complete WebSocket proxy using Python and websockets. This example authenticates the client, connects upstream, pumps messages with logging, and handles disconnects:
This proxy is stateless — it holds no session state between connections. Each WebSocket connection is an independent pass-through. You can scale horizontally by running multiple proxy instances behind a load balancer.

Client implementation

Your client connects to the proxy over WebSocket and handles WebRTC with standard browser APIs.
Once the session is running, send control messages at any time:
Message types and fields match the message reference above. In production, add reconnection logic for WebSocket drops and monitor pc.connectionState for WebRTC failures.

Next steps

HTTP Signaling

Same architecture with stateless HTTP instead of WS proxy

Authentication

API key management and client tokens