\n```\n\nthe module will be exported under `livekitclient` in the global namespace. when\naccessing symbols from the class, you'd need to prefix them with `livekitclient.`.\nfor example, `room` becomes `livekitclient.room`.\n\n## usage\n\nexamples below are in typescript, if using js/commonjs imports replace import with:\n\n```javascript\nconst livekit = require('livekit-client');\n\nconst room = new livekit.room(...);\n\n// call this some time before actually connecting to speed up the actual connection\nroom.prepareconnection(url, token);\n\nawait room.connect(...);\n```\n\n### connecting to a room, publish video & audio\n\n```typescript\nimport {\n localparticipant,\n localtrackpublication,\n participant,\n remoteparticipant,\n remotetrack,\n remotetrackpublication,\n room,\n roomevent,\n track,\n videopresets,\n} from 'livekit-client';\n\n// creates a new room with options\nconst room = new room({\n // automatically manage subscribed video quality\n adaptivestream: true,\n\n // optimize publishing bandwidth and cpu for published tracks\n dynacast: true,\n\n // default capture settings\n videocapturedefaults: {\n resolution: videopresets.h720.resolution,\n },\n});\n\n// get your url from livekit's dashboard, or point it at a self hosted livekit deployment\nconst url = \"ws://localhost:7800\";\n\n// generate a token by making a request to a endpoint using the livekit server sdk or\n// using a prebuilt tokensource (documented below)\nconst token = \"...\";\n\n// pre-warm connection, this can be called as early as your page is loaded\nroom.prepareconnection(url, token);\n\n// set up event listeners\nroom\n .on(roomevent.tracksubscribed, handletracksubscribed)\n .on(roomevent.trackunsubscribed, handletrackunsubscribed)\n .on(roomevent.activespeakerschanged, handleactivespeakerchange)\n .on(roomevent.disconnected, handledisconnect)\n .on(roomevent.localtrackunpublished, handlelocaltrackunpublished);\n\n// connect to room\nawait room.connect(url, token);\nconsole.log('connected to room', room.name);\n\n// publish local camera and mic tracks\nawait room.localparticipant.enablecameraandmicrophone();\n\nfunction handletracksubscribed(\n track: remotetrack,\n publication: remotetrackpublication,\n participant: remoteparticipant,\n) {\n if (track.kind === track.kind.video || track.kind === track.kind.audio) {\n // attach it to a new htmlvideoelement or htmlaudioelement\n const element = track.attach();\n parentelement.appendchild(element);\n }\n}\n\nfunction handletrackunsubscribed(\n track: remotetrack,\n publication: remotetrackpublication,\n participant: remoteparticipant,\n) {\n // remove tracks from all attached elements\n track.detach();\n}\n\nfunction handlelocaltrackunpublished(\n publication: localtrackpublication,\n participant: localparticipant,\n) {\n // when local tracks are ended, update ui to remove them from rendering\n publication.track.detach();\n}\n\nfunction handleactivespeakerchange(speakers: participant[]) {\n // show ui indicators when participant is speaking\n}\n\nfunction handledisconnect() {\n console.log('disconnected from room');\n}\n```\n\nin order to connect to a room, you need to first create an access token.\n\nsee [authentication docs](https://docs.livekit.io/home/get-started/authentication/) for details\n\n### handling common track types\n\nwhile 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:\n\n```typescript\nconst p = room.localparticipant;\n// turn on the local user's camera and mic, this may trigger a browser prompt\n// to ensure permissions are granted\nawait p.setcameraenabled(true);\nawait p.setmicrophoneenabled(true);\n\n// start sharing the user's screen, this will trigger a browser prompt to select\n// the screen to share.\nawait p.setscreenshareenabled(true);\n\n// disable camera to mute them, when muted, the user's camera indicator will be turned off\nawait p.setcameraenabled(false);\n```\n\nsimilarly, you can access these common track types on the other participants' end.\n\n```typescript\n// get a remoteparticipant by their identity\nconst p = room.remoteparticipants.get('participant-identity');\nif (p) {\n // if the other user has enabled their camera, attach it to a new htmlvideoelement\n if (p.iscameraenabled) {\n const publication = p.gettrackpublication(track.source.camera);\n if (publication?.issubscribed) {\n const videoelement = publication.videotrack?.attach();\n // do something with the element\n }\n }\n}\n```\n\n### creating a track prior to creating a room\n\nin some cases, it may be useful to create a track before creating a room. for\nexample, when building a staging area so the user may check their own camera.\n\nyou can use our global track creation functions for this:\n\n```typescript\nconst tracks = await createlocaltracks({\n audio: true,\n video: true,\n});\n```\n\n### publish tracks from any source\n\nlivekit 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.\n\n```typescript\nconst pub = await room.localparticipant.publishtrack(mediastreamtrack, {\n name: 'mytrack',\n simulcast: true,\n // if this should be treated like a camera feed, tag it as such\n // supported known sources are .camera, .microphone, .screenshare\n source: track.source.camera,\n});\n\n// you may mute or unpublish the track later\npub.setmuted(true);\n\nroom.localparticipant.unpublishtrack(mediastreamtrack);\n```\n\n### device management apis\n\nusers 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.\n\nwe use the same deviceid as one returned by [mediadevices.enumeratedevices()](https://developer.mozilla.org/en-us/docs/web/api/mediadevices/enumeratedevices).\n\n#### example listing and selecting a camera device\n\n```typescript\n// list all microphone devices\nconst devices = await room.getlocaldevices('audioinput');\n\n// select last device\nconst device = devices[devices.length - 1];\n\n// in the current room, switch to the selected device and set\n// it as default audioinput in the future.\nawait room.switchactivedevice('audioinput', device.deviceid);\n```\n\nyou can also switch devices given a constraint. this could be useful on mobile devices to switch to a back-facing camera:\n\n```typescript\nawait videotrack.restarttrack({\n facingmode: 'environment',\n});\n```\n\n#### handling device failures\n\nwhen 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`.\n\nyou can use the helper `mediadevicefailure.getfailure(error)` to determine specific reason for the error.\n\n- `permissiondenied` - the user disallowed capturing devices\n- `notfound` - the particular device isn't available\n- `deviceinuse` - device is in use by another process (happens on windows)\n\nthese distinctions enables you to provide more specific messaging to the user.\n\nyou could also retrieve the last error with `localparticipant.lastcameraerror` and `localparticipant.lastmicrophoneerror`.\n\n### audio playback\n\nbrowsers 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).\n\nlivekit 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.\n\nin 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.\n\n```typescript\nroom.on(roomevent.audioplaybackstatuschanged, () => {\n if (!room.canplaybackaudio) {\n // ui is necessary.\n ...\n button.onclick = () => {\n // startaudio *must* be called in an click/tap handler.\n room.startaudio().then(() => {\n // successful, ui can be removed now\n button.remove();\n });\n }\n }\n});\n```\n\n### configuring logging\n\nthis library uses [loglevel](https://github.com/pimterry/loglevel) for its internal logs. you can change the effective log level with the `loglevel` field in `connectoptions`.\nthe method `setlogextension` allows to hook into the livekit internal logs and send them to some third party logging service\n\n```ts\nsetlogextension((level: loglevel, msg: string, context: object) => {\n const enhancedcontext = { ...context, timestamp: date.now() };\n if (level >= loglevel.debug) {\n console.log(level, msg, enhancedcontext);\n }\n});\n```\n\n### generating a url/token with `tokensource`\n\na tokensource is a pre-implemented way of fetching credentials. once a `tokensource` is constructed, call\n`fetch` to generate a new set of credentials.\n\nthere are two types of `tokensource`'s - fixed and configurable. configurable token sources can be\npassed options as part of the generation process, allowing you to customize the token that they\ngenerate. fixed token sources generate static credentials and don't accept parameters that can\neffect the generated token.\n\n```ts\n// fixed token sources don't take any parameters as part of `fetch`:\nconst fixed: tokensourcefixed = /* ... */;\nconst fixedresponse = await fixed.fetch();\nroom.connect(fixedresponse.serverurl, fixedresponse.participanttoken);\n\n// configurable token sources can optionally take parameters to change what is encoded into the token:\nconst configurable: tokensourceconfigurable = /* ... */;\nconst configurableresponse = await configurable.fetch({ agentname: \"agent to dispatch\" } /* <-- here */);\nroom.connect(configurableresponse.serverurl, configurableresponse.participanttoken);\n```\n\n|mechanism: | using pre-generated credentials | via a http request to a url | via fully custom logic |\n|-------------|--|--|--|\n|fixed | `tokensource.literal` | — | `tokensource.literal(async () => { /* ... */ })` |\n|configurable | — | `tokensource.endpoint` or `tokensource.sandboxtokenserver` | `tokensource.custom` |\n\n#### tokensource.literal\na fixed token source which returns a static set of credentials or a computed set of credentials\nwith no external input required on each call.\n\nexample:\n```ts\nconst literal1 = tokensource.literal({ serverurl: \"ws://localhost:7800\", participanttoken: \"...\" });\nawait literal1.fetch() // { serverurl: \"ws://localhost:7800\", participanttoken: \"...\" }\n\nconst literal2 = tokensource.literal(async () => ({ serverurl: \"ws://localhost:7800\", participanttoken: \"...\" }));\nawait literal2.fetch() // { serverurl: \"ws://localhost:7800\", participanttoken: \"...\" }\n```\n\n#### tokensource.endpoint\na configurable token source which makes a request to an endpoint to generate credentials. by\ndefault, a `post` request with a `content-type: application/json` header is made, and the request\nbody is expected to follow the [standard token format](https://cloud.livekit.io/projects/p_/sandbox/templates/token-server). if\ncredentials generation is successful, the endpoint returns a 2xx status code with a body following\nthe [standard token response format](https://cloud.livekit.io/projects/p_/sandbox/templates/token-server).\n\nexample:\n```ts\nconst endpoint1 = tokensource.endpoint(\"http://example.com/credentials-endpoint\");\nawait endpoint1.fetch({ agentname: \"agent to dispatch\" }) // { serverurl: \"...\", participanttoken: \"... token encoding agentname ...\" }\n\nconst endpoint2 = tokensource.endpoint(\"http://example.com/credentials-endpoint\", {\n // for all supported options below, see https://developer.mozilla.org/en-us/docs/web/api/requestinit\n method: \"put\",\n headers: {\n \"x-custom-header\": \"custom header value\",\n },\n});\nawait endpoint2.fetch({ agentname: \"agent to dispatch\" }) // { serverurl: \"...\", participanttoken: \"... token encoding agentname ...\" }\n```\n\n#### tokensource.sandboxtokenserver\na configurable token source which makes a request to a\n[sandbox token server endpoint](https://cloud.livekit.io/projects/p_/sandbox/templates/token-server),\na livekit-hosted token generation mechanism.\n\nthis token generation mechanism is inherently insecure and should only be used for\nprototyping; do not use in production.\n\none parameter is required - the sandbox id from the dashboard. this is the `token-server-xxxxxx`\nvalue in `https://token-server-xxxxxx.sandbox.livekit.io`.\n\nexample:\n```ts\nconst sandbox = tokensource.sandboxtokenserver(\"token-server-xxxxxx\");\nawait sandbox.fetch({ agentname: \"agent to dispatch\" }); // { serverurl: \"...\", participanttoken: \"... token encoding agentname ...\" }\n```\n\n#### tokensource.custom\na fully custom configurable token source that allows you to consume any end application-specific\ntoken generation mechanism. tokens that are generated are cached and used until they expire or the\noptions passed into `fetch` change.\n\nnote that it is expected that all options passed into `fetch` will always be encoded into the\noutput token. if you'd rather implement a fixed version of this tokensource, see\n`tokensource.literal(async () => { /* ... */ })`.\n\nexample:\n```ts\nconst sandbox = tokensource.custom(async (options) => {\n // generate token info via custom means here\n return { serverurl: \"...\", participanttoken: \"... options encoded in here ...\" };\n});\nawait sandbox.fetch({ agentname: \"agent to dispatch\" });\n```\n\n### rpc\n\nperform your own predefined method calls from one participant to another.\n\nthis feature is especially powerful when used with [agents](https://docs.livekit.io/agents), for instance to forward llm function calls to your client application.\n\n#### registering an rpc method\n\nthe participant who implements the method and will receive its calls must first register support:\n\n```typescript\nroom.localparticipant?.registerrpcmethod(\n // method name - can be any string that makes sense for your application\n 'greet',\n\n // method handler - will be called when the method is invoked by a remoteparticipant\n async (data: rpcinvocationdata) => {\n console.log(`received greeting from ${data.calleridentity}: ${data.payload}`);\n return `hello, ${data.calleridentity}!`;\n },\n);\n```\n\nin 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.\n\n#### performing an rpc request\n\nthe caller may then initiate an rpc call like so:\n\n```typescript\ntry {\n const response = await room.localparticipant!.performrpc({\n destinationidentity: 'recipient-identity',\n method: 'greet',\n payload: 'hello from rpc!',\n });\n console.log('rpc response:', response);\n} catch (error) {\n console.error('rpc call failed:', error);\n}\n```\n\nyou 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.\n\n#### errors\n\nlivekit is a dynamic realtime environment and calls can fail for various reasons.\n\nyou 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`.\n\n## error codes\n\n| code | name | reason |\n| ----- | --------------------------- | ------------------ |\n| 1 | `connectionerror` | 0: `notallowed`
1: `serverunreachable`
2: `internalerror`
3: `cancelled`
4:`leaverequest` |\n| 10 | `unsupportedserver` | |\n| 12 | `unexpectedconnectionstate` | |\n| 13 | `negotiationerror` | |\n| 14 | `publishdataerror` | |\n| 15 | `signalrequesterror` | |\n| 20 | `trackinvaliderror` | |\n| 21 | `deviceunsupportederror` | |\n| 40 | `cryptorerror` | |\n\n## examples\n\n### demo app\n\n[examples/demo](https://github.com/livekit/client-sdk-js/tree/main/examples/demo/) contains a demo webapp that uses the sdk. run it with `pnpm install && pnpm examples:demo`\n\n### rpc demo\n\n[examples/rpc](https://github.com/livekit/client-sdk-js/tree/main/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.\n\n## browser support\n\n| browser | desktop os | mobile os |\n| --------------- | --------------------- | --------- |\n| chrome | windows, macos, linux | android |\n| firefox | windows, macos, linux | android |\n| safari | macos | ios |\n| edge (chromium) | windows, macos | |\n\nwe aim to support a broad range of browser versions by transpiling the library code with babel.\nyou can have a look at the `\"browerslist\"` section of `package.json` for more details.\n\n> note that the library requires some specific browser apis to be present.\n> you can check general compatibility with the helper function `isbrowsersupported()`.\n> support for more modern features like adaptivestream and dynacast can be checked for with `supportsadaptivestream()` and `supportsdynacast()`.\n\nif you are targeting legacy browsers, but still want adaptivestream functionality you'll likely need to use polyfills for [resizeobserver](https://www.npmjs.com/package/resize-observer-polyfill) and [intersectionobserver](https://www.npmjs.com/package/intersection-observer).\n\nalso 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.\n\n\n
\n\n\n\n\n\n\n\n\n\n\n\n
livekit ecosystem
agents sdkspython \u00b7 node.js
livekit sdksbrowser \u00b7 swift \u00b7 android \u00b7 flutter \u00b7 react native \u00b7 rust \u00b7 node.js \u00b7 python \u00b7 unity \u00b7 unity (webgl) \u00b7 esp32 \u00b7 c++
starter appspython agent \u00b7 typescript agent \u00b7 react app \u00b7 swiftui app \u00b7 android app \u00b7 flutter app \u00b7 react native app \u00b7 web embed
ui componentsreact \u00b7 android compose \u00b7 swiftui \u00b7 flutter
server apisnode.js \u00b7 golang \u00b7 ruby \u00b7 java/kotlin \u00b7 python \u00b7 rust \u00b7 php (community) \u00b7 .net (community)
resourcesdocs \u00b7 docs mcp server \u00b7 cli \u00b7 livekit cloud
livekit server osslivekit server \u00b7 egress \u00b7 ingress \u00b7 sip
communitydeveloper community \u00b7 slack \u00b7 x \u00b7 youtube
\n", "installation_instructions": null, "categories": [ "Everything" ], "owners": [], "owner": null, "code_snippets": {}, "evaluation_results": [], "found_via_ownership_request": false, "hosting_eligible": false, "knative_enabled": false, "security_scans": [] } }