JavaScript/TypeScript client SDK for LiveKit

Use this SDK to add realtime video, audio and data features to your JavaScript/TypeScript app. By connecting to LiveKit Cloud or a self-hosted server, you can quickly build applications such as multi-modal AI, live streaming, or video calls with just a few lines of code.

Docs

Docs and guides at https://docs.livekit.io

SDK reference

> [!NOTE]
> This is v2 of livekit-client. When migrating from v1.x to v2.x you might encounter a small set of breaking changes.
> Read the migration guide for a detailed overview of what has changed.

Installation

$3

``shell
yarn add livekit-client
`

$3

`shell
npm install livekit-client --save
`

$3

To use the SDK without a package manager, you can include it with a script tag:

`html

`

The module will be exported under LivekitClient in the global namespace. When
accessing symbols from the class, you'd need to prefix them with LivekitClient..
For example, Room becomes LivekitClient.Room.

Usage

Examples below are in TypeScript, if using JS/CommonJS imports replace import with:

`javascript
const livekit = require('livekit-client');

const room = new livekit.Room(...);

// call this some time before actually connecting to speed up the actual connection
room.prepareConnection(url, token);

await room.connect(...);
`

$3

`typescript
import {
LocalParticipant,
LocalTrackPublication,
Participant,
RemoteParticipant,
RemoteTrack,
RemoteTrackPublication,
Room,
RoomEvent,
Track,
VideoPresets,
} from 'livekit-client';

// creates a new room with options
const room = new Room({
// automatically manage subscribed video quality
adaptiveStream: true,

// optimize publishing bandwidth and CPU for published tracks
dynacast: true,

// default capture settings
videoCaptureDefaults: {
resolution: VideoPresets.h720.resolution,
},
});

// get your url from livekit's dashboard, or point it at a self hosted livekit deployment
const url = "ws://localhost:7800";

// generate a token by making a request to a endpoint using the livekit server sdk or
// using a prebuilt TokenSource (documented below)
const token = "...";

// pre-warm connection, this can be called as early as your page is loaded
room.prepareConnection(url, token);

// set up event listeners
room
.on(RoomEvent.TrackSubscribed, handleTrackSubscribed)
.on(RoomEvent.TrackUnsubscribed, handleTrackUnsubscribed)
.on(RoomEvent.ActiveSpeakersChanged, handleActiveSpeakerChange)
.on(RoomEvent.Disconnected, handleDisconnect)
.on(RoomEvent.LocalTrackUnpublished, handleLocalTrackUnpublished);

// connect to room
await room.connect(url, token);
console.log('connected to room', room.name);

// publish local camera and mic tracks
await room.localParticipant.enableCameraAndMicrophone();

function handleTrackSubscribed(
track: RemoteTrack,
publication: RemoteTrackPublication,
participant: RemoteParticipant,
) {
if (track.kind === Track.Kind.Video || track.kind === Track.Kind.Audio) {
// attach it to a new HTMLVideoElement or HTMLAudioElement
const element = track.attach();
parentElement.appendChild(element);
}
}

function handleTrackUnsubscribed(
track: RemoteTrack,
publication: RemoteTrackPublication,
participant: RemoteParticipant,
) {
// remove tracks from all attached elements
track.detach();
}

function handleLocalTrackUnpublished(
publication: LocalTrackPublication,
participant: LocalParticipant,
) {
// when local tracks are ended, update UI to remove them from rendering
publication.track.detach();
}

function handleActiveSpeakerChange(speakers: Participant[]) {
// show UI indicators when participant is speaking
}

function handleDisconnect() {
console.log('disconnected from room');
}
`

In order to connect to a room, you need to first create an access token.

See authentication docs for details

$3

While LiveKit is designed to be flexible, we've added a few shortcuts that makes working with common track types simple. For a user's camera, microphone, and screen share, you can enable them with the following LocalParticipant methods:

`typescript
const p = room.localParticipant;
// turn on the local user's camera and mic, this may trigger a browser prompt
// to ensure permissions are granted
await p.setCameraEnabled(true);
await p.setMicrophoneEnabled(true);

// start sharing the user's screen, this will trigger a browser prompt to select
// the screen to share.
await p.setScreenShareEnabled(true);

// disable camera to mute them, when muted, the user's camera indicator will be turned off
await p.setCameraEnabled(false);
`

Similarly, you can access these common track types on the other participants' end.

`typescript
// get a RemoteParticipant by their identity
const p = room.remoteParticipants.get('participant-identity');
if (p) {
// if the other user has enabled their camera, attach it to a new HTMLVideoElement
if (p.isCameraEnabled) {
const publication = p.getTrackPublication(Track.Source.Camera);
if (publication?.isSubscribed) {
const videoElement = publication.videoTrack?.attach();
// do something with the element
}
}
}
`

$3

In some cases, it may be useful to create a track before creating a room. For
example, when building a staging area so the user may check their own camera.

You can use our global track creation functions for this:

`typescript
const tracks = await createLocalTracks({
audio: true,
video: true,
});
`

$3

LiveKit lets you publish any track as long as it can be represented by a MediaStreamTrack. You can specify a name on the track in order to identify it later.

`typescript
const pub = await room.localParticipant.publishTrack(mediaStreamTrack, {
name: 'mytrack',
simulcast: true,
// if this should be treated like a camera feed, tag it as such
// supported known sources are .Camera, .Microphone, .ScreenShare
source: Track.Source.Camera,
});

// you may mute or unpublish the track later
pub.setMuted(true);

room.localParticipant.unpublishTrack(mediaStreamTrack);
`

$3

Users may have multiple input and output devices available. LiveKit will automatically use the one that's deemed as the default device on the system. You may also list and specify an alternative device to use.

We use the same deviceId as one returned by MediaDevices.enumerateDevices().

#### Example listing and selecting a camera device

`typescript
// list all microphone devices
const devices = await Room.getLocalDevices('audioinput');

// select last device
const device = devices[devices.length - 1];

// in the current room, switch to the selected device and set
// it as default audioinput in the future.
await room.switchActiveDevice('audioinput', device.deviceId);
`

You can also switch devices given a constraint. This could be useful on mobile devices to switch to a back-facing camera:

`typescript
await videoTrack.restartTrack({
facingMode: 'environment',
});
`

#### Handling device failures

When creating tracks using LiveKit APIs (connect, createLocalTracks, setCameraEnabled, etc), it's possible to encounter errors with the underlying media device. In those cases, LiveKit will emit RoomEvent.MediaDevicesError.

You can use the helper MediaDeviceFailure.getFailure(error) to determine specific reason for the error.

- PermissionDenied - the user disallowed capturing devices
- NotFound - the particular device isn't available
- DeviceInUse - device is in use by another process (happens on Windows)

These distinctions enables you to provide more specific messaging to the user.

You could also retrieve the last error with LocalParticipant.lastCameraError and LocalParticipant.lastMicrophoneError.

$3

Browsers can be restrictive with regards to audio playback that is not initiated by user interaction. What each browser considers as user interaction can vary by vendor (for example, Safari on iOS is very restrictive).

LiveKit will attempt to autoplay all audio tracks when you attach them to audio elements. However, if that fails, we'll notify you via RoomEvent.AudioPlaybackStatusChanged. Room.canPlaybackAudio will indicate if audio playback is permitted. LiveKit takes an optimistic approach so it's possible for this value to change from true to false when we encounter a browser error.

In the case user interaction is required, LiveKit provides Room.startAudio to start audio playback. This function must be triggered in an onclick or ontap event handler. In the same session, once audio playback is successful, additional audio tracks can be played without further user interactions.

`typescript
room.on(RoomEvent.AudioPlaybackStatusChanged, () => {
if (!room.canPlaybackAudio) {
// UI is necessary.
...
button.onclick = () => {
// startAudio must be called in an click/tap handler.
room.startAudio().then(() => {
// successful, UI can be removed now
button.remove();
});
}
}
});
`

$3

This library uses loglevel for its internal logs. You can change the effective log level with the logLevel field in ConnectOptions.
The method setLogExtension allows to hook into the livekit internal logs and send them to some third party logging service

`ts
setLogExtension((level: LogLevel, msg: string, context: object) => {
const enhancedContext = { ...context, timeStamp: Date.now() };
if (level >= LogLevel.debug) {
console.log(level, msg, enhancedContext);
}
});
`

$3

A TokenSource is a pre-implemented way of fetching credentials. Once a TokenSource is constructed, call
fetch to generate a new set of credentials.

There are two types of TokenSource's - fixed and configurable. Configurable token sources can be
passed options as part of the generation process, allowing you to customize the token that they
generate. Fixed token sources generate static credentials and don't accept parameters that can
effect the generated token.

`ts
// Fixed token sources don't take any parameters as part of fetch:
const fixed: TokenSourceFixed = / ... /;
const fixedResponse = await fixed.fetch();
room.connect(fixedResponse.serverUrl, fixedResponse.participantToken);

// Configurable token sources can optionally take parameters to change what is encoded into the token:
const configurable: TokenSourceConfigurable = / ... /;
const configurableResponse = await configurable.fetch({ agentName: "agent to dispatch" } / <-- here /);
room.connect(configurableResponse.serverUrl, configurableResponse.participantToken);
`

|Mechanism: | using pre-generated credentials | via a http request to a url | via fully custom logic |
|-------------|--|--|--|
|Fixed | TokenSource.literal | — | TokenSource.literal(async () => { / ... / }) |
|Configurable | — | TokenSource.endpoint or TokenSource.sandboxTokenServer | TokenSource.custom |

#### TokenSource.Literal
A fixed token source which returns a static set of credentials or a computed set of credentials
with no external input required on each call.

Example:
`ts
const literal1 = TokenSource.literal({ serverUrl: "ws://localhost:7800", participantToken: "..." });
await literal1.fetch() // { serverUrl: "ws://localhost:7800", participantToken: "..." }

const literal2 = TokenSource.literal(async () => ({ serverUrl: "ws://localhost:7800", participantToken: "..." }));
await literal2.fetch() // { serverUrl: "ws://localhost:7800", participantToken: "..." }
`

#### TokenSource.Endpoint
A configurable token source which makes a request to an endpoint to generate credentials. By
default, a POST request with a Content-Type: application/json header is made, and the request
body is expected to follow the standard token format. If
credentials generation is successful, the endpoint returns a 2xx status code with a body following
the standard token response format.

Example:
`ts
const endpoint1 = TokenSource.endpoint("http://example.com/credentials-endpoint");
await endpoint1.fetch({ agentName: "agent to dispatch" }) // { serverUrl: "...", participantToken: "... token encoding agentName ..." }

const endpoint2 = TokenSource.endpoint("http://example.com/credentials-endpoint", {
// For all supported options below, see https://developer.mozilla.org/en-US/docs/Web/API/RequestInit
method: "PUT",
headers: {
"X-Custom-Header": "custom header value",
},
});
await endpoint2.fetch({ agentName: "agent to dispatch" }) // { serverUrl: "...", participantToken: "... token encoding agentName ..." }
`

#### TokenSource.SandboxTokenServer
A configurable token source which makes a request to a
sandbox token server endpoint,
a LiveKit-hosted token generation mechanism.

This token generation mechanism is inherently insecure and should only be used for
prototyping; do NOT use in production.

One parameter is required - the sandbox id from the dashboard. This is the token-server-xxxxxx
value in https://token-server-xxxxxx.sandbox.livekit.io.

Example:
`ts
const sandbox = TokenSource.sandboxTokenServer("token-server-xxxxxx");
await sandbox.fetch({ agentName: "agent to dispatch" }); // { serverUrl: "...", participantToken: "... token encoding agentName ..." }
`

#### TokenSource.Custom
A fully custom configurable token source that allows you to consume any end application-specific
token generation mechanism. Tokens that are generated are cached and used until they expire or the
options passed into fetch change.

Note that it is expected that all options passed into fetch will always be encoded into the
output token. If you'd rather implement a fixed version of this TokenSource, see
TokenSource.literal(async () => { / ... / }).

Example:
`ts
const sandbox = TokenSource.custom(async (options) => {
// generate token info via custom means here
return { serverUrl: "...", participantToken: "... options encoded in here ..." };
});
await sandbox.fetch({ agentName: "agent to dispatch" });
`

$3

Perform your own predefined method calls from one participant to another.

This feature is especially powerful when used with Agents, for instance to forward LLM function calls to your client application.

#### Registering an RPC method

The participant who implements the method and will receive its calls must first register support:

`typescript
room.localParticipant?.registerRpcMethod(
// method name - can be any string that makes sense for your application
'greet',

// method handler - will be called when the method is invoked by a RemoteParticipant
async (data: RpcInvocationData) => {
console.log(Received greeting from ${data.callerIdentity}: ${data.payload});
return Hello, ${data.callerIdentity}!;
},
);
`

In addition to the payload, your handler will also receive responseTimeout, which informs you the maximum time available to return a response. If you are unable to respond in time, the call will result in an error on the caller's side.

#### Performing an RPC request

The caller may then initiate an RPC call like so:

`typescript
try {
const response = await room.localParticipant!.performRpc({
destinationIdentity: 'recipient-identity',
method: 'greet',
payload: 'Hello from RPC!',
});
console.log('RPC response:', response);
} catch (error) {
console.error('RPC call failed:', error);
}
`

You may find it useful to adjust the responseTimeout parameter, which indicates the amount of time you will wait for a response. We recommend keeping this value as low as possible while still satisfying the constraints of your application.

#### Errors

LiveKit is a dynamic realtime environment and calls can fail for various reasons.

You may throw errors of the type RpcError with a string message in an RPC method handler and they will be received on the caller's side with the message intact. Other errors will not be transmitted and will instead arrive to the caller as 1500 ("Application Error"). Other built-in errors are detailed in RpcError.

Error Codes

| Code | Name | Reason |
| ----- | --------------------------- | ------------------ |
| 1 | ConnectionError | 0: NotAllowed
1: ServerUnreachable
2: InternalError
3: Cancelled
4:LeaveRequest |
| 10 | UnsupportedServer | |
| 12 | UnexpectedConnectionState | |
| 13 | NegotiationError | |
| 14 | PublishDataError | |
| 15 | SignalRequestError | |
| 20 | TrackInvalidError | |
| 21 | DeviceUnsupportedError | |
| 40 | CryptorError | |

Examples

$3

examples/demo contains a demo webapp that uses the SDK. Run it with pnpm install && pnpm examples:demo

$3

examples/rpc contains a demo webapp that uses the SDK to showcase the RPC capabilities. Run it with pnpm install && pnpm dev from the examples/rpc directory.

Browser Support

| Browser | Desktop OS | Mobile OS |
| --------------- | --------------------- | --------- |
| Chrome | Windows, macOS, Linux | Android |
| Firefox | Windows, macOS, Linux | Android |
| Safari | macOS | iOS |
| Edge (Chromium) | Windows, macOS | |

We aim to support a broad range of browser versions by transpiling the library code with babel.
You can have a look at the "browerslist" section of package.json for more details.

> Note that the library requires some specific browser APIs to be present.
> You can check general compatibility with the helper function isBrowserSupported().
> Support for more modern features like adaptiveStream and dynacast can be checked for with supportsAdaptiveStream() and supportsDynacast()`.

If you are targeting legacy browsers, but still want adaptiveStream functionality you'll likely need to use polyfills for ResizeObserver and IntersectionObserver.

Also when targeting legacy browsers, older than the ones specified in our browserslist target, make sure to transpile the library code to your desired target and include required polyfills with babel and/or corejs.