ClutchCall is modality-oriented. Pick the modality that matches what you build: voice, streams, robotics, games, or data. Then import its sub-client. All five modalities use the same MoQT relay mesh. This page shows a worked example in TypeScript. Each per-language quickstart shows the same pattern in that SDK’s idiom.

1. Install

npm
The package includes the WASM core. The browser needs no separate native install. Native Node / Python / Go / Rust / Java / .NET SDKs also load clutchcall_core_ffi.{so,dylib,dll}. See each per-language installation page.

2. Get a token

Every modality authenticates with a tenant token. The relay checks the token through its namespace-auth hook. The control-plane API key (tRPC, CLUTCHCALL_CREDENTIALS) mints data-plane tokens. Each token is scoped to the namespaces that the client needs.
See Authentication for the full key model (API key → relay token mint → namespace-scoped JWT).

3. Pick a modality

What just happened

  1. The SDK opened a QUIC link to relay.clutchcall.dev:443 over MoQT. In the browser, the SDK used WebTransport. The tenant token authorized the session.
  2. For control-plane modality methods (v.calls.originate, streams.liveInputs.create, etc.), the SDK called tRPC procedures on the control-plane API over HTTP/3.
  3. For data-plane methods (subscribeState, publishInput, etc.), the SDK opened MoQT publish / subscribe requests. The relay fans these out to every matching subscriber.
The same connection survives reconnects. See Realtime Tracks for the auto-reconnect model.

Next steps

Modalities overview

The five-modality model and when to pick each modality.

Architecture

The MoQT relay mesh, the C++ core, and how the modality layer fits.

Authentication

API keys, relay tokens, namespace-auth, and JWT signing.

SDK Reference

A reference for every modality, every method, and every language.