Channel Types

Every channel has a type, and you choose it when you create or fetch the channel. The type decides which features are enabled and how permissions work, so it determines what your users can actually do in that channel: whether typing indicators appear, whether reactions and threads exist, whether uploads are allowed, and whether membership is required to read or post.

You pass the type when you create a channel. See Creating Channels for the call in your SDK.

Built-in Channel types

There are five built-in channel types with good default for these use cases.

• Messaging: Good default for dating, marketplace, and other social app chat use cases
• AI: For creating user to LLM style chat experiences, text, voice & video.
• Livestream: For livestreaming or live shopping experiences
• Team: If you want to build your own version of Slack or something similar, start here.
• Gaming: Defaults for adding chat to video games.

The five default channel types come with good default permission policies. You can find more information on how to manage permissions in the Permissions Reference.

The livestream type is the one that behaves most differently from the rest: it does not require membership to read or write, so any user with a valid token can watch and post. That is why it is the recommended starting point for live events. See Livestream Best Practices.

Features controlled by the channel type

If a feature does not work in your app, check the type's configuration before debugging your client code. These are the flags that change client behaviour:

• typing_events : Controls if typing indicators are shown.
• read_events : Controls whether the chat shows how far you've read.
• connect_events : Determines if events are fired for connecting and disconnecting to a chat.
• custom_events : Determines if channel watchers will receive custom events.
• reactions : If users are allowed to add reactions to messages.
• search : Controls if messages should be searchable.
• replies : Enables message threads and replies.
• quotes : Allows members to quote messages (inline replies).
• mutes : Determines if users are able to mute other users.
• uploads : Allows image and file uploads within messages.
• url_enrichment : When enabled, messages containing URLs will be enriched automatically with image and text related to the message. This is disabled by default for the livestream channel type and we do not recommend enabling it for performance reasons.
• count_messages : Enables message counting on new channels. When enabled the message count will be present in the channel response.
• user_message_reminders : Allow users to set reminders for messages. More information can be found here.
• mark_messages_pending : When enabled, messages marked as pending are only visible to the sender until approved.
• polls : Allows channel members to create and vote on polls.
• skip_last_msg_update_for_system_msgs : When disabled, system messages will affect the channel's last_message_at timestamp.
• location_sharing : Allows members to share their locations with other members.
• read_receipts : Allows members to see when messages are delivered (delivery events).
• partitioning : Automatically chunks messages into virtual partitions for better performance at larger scales (dynamic partitioning).
• push_notifications : If messages are allowed to generate push notifications.

Two limits are worth knowing about, because both surface as errors on the client. max_message_length defaults to 5,000 characters, and a longer message is rejected with Stream code 20. Trying to use a feature the type has disabled is rejected with Stream code 19. Both are listed on the API Errors & Response page.

Your app's channel types and their current settings are also returned by the channel endpoints, so you can read the configuration your client received rather than assuming the defaults. The full field list with defaults is in the server docs.