Namespace Livekit.Server.Sdk.Dotnet

Access tokens, webhooks and clients of the LiveKit server APIs, for a .NET backend.

AccessToken signs the tokens participants join rooms with; VideoGrants and SIPGrants say what they may do.
RoomServiceClient, EgressServiceClient, IngressServiceClient, SipServiceClient, AgentDispatchServiceClient and ConnectorServiceClient call the server APIs.
WebhookReceiver verifies and parses the webhooks LiveKit posts.
TwirpException is the error of a failed service call.

The other types of this namespace are the protobuf messages of the requests, responses and events, generated from livekit/protocol.

Classes

APICallInfo

APICallRequest

AcceptWhatsAppCallRequest

AcceptWhatsAppCallResponse

AccessToken: Access tokens are required to connect to the server. Once information is filled out, create the token string with ToJwt(). See Access tokens and grants.

ActiveSpeakerUpdate

AddTrackRequest

AgentDeployment

AgentDispatch

AgentDispatchServiceClient: Client of the LiveKit Agent Dispatch service: dispatches agents to rooms explicitly, lists and deletes those dispatches.

AgentDispatchState

AgentEvent

AgentHttp

----- agent HTTP endpoints data plane -----

AgentHttp namespaces the data plane: workers expose HTTP endpoints served at /agents/{agent_name}/{deployment}/{path} without binding any local listener. The worker opens ONE WebTransport (QUIC) session to /agent that carries both its control stream (the same WorkerMessage/ServerMessage exchange as the WebSocket control connection, length-delimited) and every HTTP exchange: the node opens one bidirectional QUIC stream per request. QUIC provides the multiplexing and per-stream flow control, so there is no credit accounting and no attach handshake.

Each exchange stream is:

[len:u32be][StreamPreamble] the only LiveKit framing [ ... opaque bytes ... ] one HTTP/1.1 exchange, to FIN or RESET_STREAM

After the preamble the stream is byte-transparent: the node writes a canonical HTTP/1.1 request and the worker replies with an HTTP/1.1 response, each parsed by whatever HTTP implementation the side already has. A WebSocket upgrade is therefore an ordinary request whose response is a 101, after which the stream is a byte pipe. The protocol evolves by version negotiation at registration, so the preamble carries no version of its own.

Bodies use ordinary HTTP/1.1 framing, Content-Length or chunked, and are unbounded: a body may be many gigabytes and must be streamed. Request and response size limits are policy for the layer above.

How one direction ends:

success end of message per the body's own framing, then FIN. failed mid-body chunked trailer fields x-lk-completion and x-lk-error, in band, so the outcome cannot race the bytes it describes. failed before any RESET_STREAM carrying an HttpStreamResetCode, sound bytes only here, where nothing is in flight.

FIN before the body's own framing says it is complete is truncation, and a receiver must surface it as such.

The x-lk- header prefix is reserved for this signalling in both directions. A node strips it from client-supplied request headers, so a client cannot forge one, and strips it from responses, so it never reaches the end client.

Table of Contents

Namespace Livekit.Server.Sdk.Dotnet

Classes

Enums