Client & Authentication

Before joining a call, it is necessary to set up the video client. Here's a basic example:

  1. Create the IStreamVideoClient instance

    _client = StreamVideoClient.CreateDefaultClient();
  2. Connect user to the Stream API

    var authCredentials = new AuthCredentials("api-key", "user-id", "user-token");
    await _client.ConnectUserAsync(authCredentials);
  • The API Key can be found in your Stream dashboard.
  • The User can be either authenticated, anonymous or guest.
  • Note: You can store custom data on the user object, if required.

Here's a complete example of a MonoBehaviour that initiates the client and connects to the Stream API:

using System;
using StreamVideo.Core;
using StreamVideo.Libs.Auth;
using UnityEngine;

public class VideoClient : MonoBehaviour
{
    async void Start()
    {
        _client = StreamVideoClient.CreateDefaultClient();

        try
        {
            var authCredentials = new AuthCredentials("api-key", "user-id", "user-token");
            await _client.ConnectUserAsync(authCredentials);

            // After we awaited the ConnectUserAsync the client is connected
        }
        catch (Exception e)
        {
            Debug.LogError(e.Message);
        }
    }

    private IStreamVideoClient _client;
}

Generating a token

Tokens provide a way to authenticate a user or give access to a specific set of calls. They're similar to passwords but offer more flexibility, allowing you to set the expiry date. For security reasons, tokens need to be generated server-side. Typically, you integrate this into the part of your codebase where you login or register users. You can use our server-side SDKs to easily add support for this. For detailed instruction, refer to our server-side docs on installation and users and tokens.

Here's a valid user and token to help you get started on the client side before integrating with your backend API:

Here are credentials to try out the app with:

PropertyValue
API Keyundefined
Tokenundefined
User IDundefined
Call IDundefined

For testing you can join the call on our web-app: Join Call

Client options

Here's an example showing how you can pass configuration options through the StreamClientConfig instance passed to the CreateDefaultClient method:

var config = new StreamClientConfig
{
    // Enabling Debug level logging can be helpful during development
    LogLevel = StreamLogLevel.Debug,
    Audio =
    {
        // RED sends redundant audio data, improving audio quality on lossy
        // networks in exchange for higher bandwidth
        EnableRed = false,

        // DTX encodes silence at a lower bitrate, saving bandwidth and battery
        EnableDtx = false
    },
    Video =
    {
        // The resolution requested for incoming participant video.
        // Defaults to Res_1080p - lower it to save bandwidth in larger calls.
        DefaultParticipantVideoResolution = VideoResolution.Res_720p
    }
};
_client = StreamVideoClient.CreateDefaultClient(config);

Both audio options are off by default — the snippet above shows the defaults. Set them to true when:

OptionWhen to enable
EnableRedRecommended when your users are on lossy networks or audio quality matters a lot. Because it makes audio packets larger, it may not suit calls with a large number of participants.
EnableDtxA good choice for conferences where participants don't speak simultaneously. Not suitable for music streaming — DTX is optimized for human speech and can degrade music quality.

Video.DefaultParticipantVideoResolution sets the resolution requested for every incoming participant, and defaults to VideoResolution.Res_1080p. See Video Optimization for how to tune this per participant at runtime.

LogLevel accepts four values:

ValueDescription
StreamLogLevel.FailureOnlyOnly errors are logged. This is the default and is recommended for production.
StreamLogLevel.AllAll errors are logged. Useful during development.
StreamLogLevel.DebugEverything in All, plus additional logs that can help with debugging.
StreamLogLevel.DisabledNo logs are emitted. Only viable if you capture and log all thrown exceptions yourself.