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 six built-in channel types with good default for these use cases.

• Messaging: Good default for dating, marketplace, and other social app chat use cases
• Agent: For conversations between a user and an AI agent.
• 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.
• Commerce: For conversations between customers and businesses, such as marketplace and support chat.

The six 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.

The agent type is meant for AI conversations. Membership is required to read and write, as on messaging, but users and guest users can create agent channels from the client, including channels with your agent's user as a member, and the creator keeps owner permissions on the channel. Typing events are off (use the AI indicator events from AI Message Streaming instead), there are no slash commands, so a message starting with / is sent as plain text, and messages can be up to 50,000 characters with up to 50 KB of custom data. See The agent channel type in the server docs for the full defaults.

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 (50,000 on the agent type), 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.