Integration paths
Decart realtime models use WebRTC for media (video and audio) and a control plane for signaling, prompts, and session events. Each integration path differs in how you connect to the control plane — media quality is identical across all paths.| Path | How it works | White-label | Provider visibility | Client requirements | Your infrastructure |
|---|---|---|---|---|---|
| SDK Direct | Your app embeds the Decart SDK | No | Session events only | WebRTC + Decart SDK | Token minting only |
| WS Signaling Proxy | You proxy WebSocket signaling, WebRTC stays direct | Yes | Full | WebRTC (no SDK) | WS proxy server |
| HTTP Signaling | You proxy stateless HTTP calls, WebRTC stays direct | Yes | Full | WebRTC (no SDK) | Stateless HTTP proxy |
Choosing a path
Do you need white-label? If it’s OK for your users to connect to Decart endpoints directly (visible in network traffic) and depend on the Decart SDK, use SDK Direct — it’s the simplest path with zero infrastructure overhead. If you do need white-label, choose based on your infrastructure: if your gateway is HTTP-native (most API platforms), use HTTP Signaling. If you already run WebSocket infrastructure, use WS Signaling Proxy. Both deliver identical media quality.Authentication
All integration paths use the same authentication system. You receive a Decart API key for your platform and use it to authenticate requests on behalf of your users.- Permanent keys are used server-side to authenticate with Decart
- Client tokens are short-lived keys for browser/mobile use — see Client Tokens
- Usage is tracked per API key, so you get full visibility into your users’ consumption
Your API key is scoped to your platform. Decart tracks usage per key, so you can query consumption and build your own billing on top.