Stream

Introduction

Copied!

Welcome to REST API documentation for Stream Chat!

It explains the Chat API concepts.

Please note

Copied!

The REST documentation is recommended for advanced users that want to write their own API clients. Have a look below at the official clients, framework integrations, and community-contributed libraries.

Always feel free to get in touch if you have questions.

Are you looking for a ready-made client or framework library?

Copied!

If you're looking to get started quickly, official clients are available for most popular languages including Ruby, JavaScript, Python, PHP, Go, and more.

First steps

Copied!

1. Complete 'Getting Started'

Copied!

Before you start writing your client, we recommend that you complete the getting started tutorial. It explains the Chat API concepts, and allows you to get familiar with Stream.

2. Review Official Clients

Copied!

Reviewing the official Stream API clients is a great source of inspiration for writing your own client.

A good starting point is the official JavaScript client as it runs its test suite in the browser.

You can review all of our open-source libraries at the official Stream GitHub page.

3. Browse Documentation

Copied!

This documentation page includes all API endpoints and describes the three authentication available to use Stream Chat.

Got stuck? No worries at all, feel free to contact support at any time.

Basics

Copied!

Hostname

Copied!

The hostname of the API is https://chat.stream-io-api.com

Common Parameters

Copied!

Every request should contain api_key query parameter and appropriate authorization header

nametypedescriptiondefaultoptional
api_keystringApplication public API key-

Compression

Copied!

Stream API supports gzip and deflate compression, make sure that your client negotiate compression. Enabling compression can reduce significantly latency and used bandwidth and it's highly recommended.

JSON

Copied!

Unless specified differently, all request body data must be JSON encoded and all responses are also JSON encoded.

Authentication

Copied!

API Keys and Tokens

Copied!

Every API request to Stream must include: the API Key of the app performing the request and an authentication token generated using the API Key secret. Token must be a JWT token including a signature generated with the HS256 algorithm.

If you are not familiar with JWT we highly recommend reading more about it here. Libraries to generate JWT are available for most programming languages. The full list is available here.

The authentication token must include the correct claims (also called payload). A token valid for a type of request or for a user_id might not be valid for another one. Your application should generate the appropriate token; when using client-side auth, each user should have its own unique token.

Sending an Authenticated Request

Copied!

All API requests to Stream must include a query parameter called api_key with the API Key in use. Once the token is generated correctly it is used to authenticate a request. This is done by setting two HTTP headers on the request:

Header

Value

Description

Stream-Auth-Type

jwt

Sets authentication type. Possible values: jwt, anonymous

Authorization

<token>

Sets JWT authentication token when jwt auth type is used

Some HTTP libraries prefix token with "Bearer " string. This prefix should be removed before sending the request to Stream.

When dealing with authentication tokens, you should keep in mind that tokens are like passwords. Never share tokens with untrusted parties.

Server-side

Copied!

Requests from a back-end application to Stream Chat API should use Server-Side Authentication to authenticate requests.

JWT Usage for Server-side Authentication

Copied!

For server-side authentication, the application should send a token that is signed with the API Secret of the Stream app. This token must not include any claim beside claims defined by JWT specifications (ie. "iat", "exp", ...).

When using server-side authentication; there will be no permission checking and you will be able to perform any valid request for any of your user.

You should never share a server-side token with any untrusted party or use it directly on the mobile or web-browser. If your API secret or server-side token gets compromised you should create a new API Key from the dashboard and delete the one that got compromised.

Some endpoints can only used with server-side auth; ie. changing the configuration of your application or perform other actions such as changing users' role.

Token Example

Copied!

Here is the server-side token for a fictional application with API Secret "top-secret": eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.e30.-hJRcjmUOcS0P-Pllpe8gnOtMINmm7Ktebd3eKUroAc

Client-side

Copied!

Requests from a front-end application to the Stream Chat API should use Client-Side Authentication to authenticate requests.

JWT Usage For Client-side Authentication

Copied!

When using client-side auth, you generate different token to each of your user and include their string ID in the user_id claim.

A common approach is to have your users authenticate with your app server-side and to provision a user token so that API calls to Stream can be done on their behalf directly on your mobile/web app.

For security reasons, some API endpoints and some specific actions can be performed only server-side.

User tokens will effectively authenticate the user based on the user_id claim. After that all API calls will be checked for permissions.

More information about permissions is available on Chat Documentation.

Token Example

Copied!

Here is the user token for user "jack" on a fictional application with API Secret "top-secret": eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoiamFjayJ9.pO3Fa8TJnPXsl62-XHK94S8hFk6dUz_2Q9au6H5xBSQ

Anonymous

Copied!

Anonymous authentication allows you to use a sub-set of Chat's API without generating a user token.

Anonymous authentication works exactly as client-side auth with a couple of exceptions:

  • You must not send the Authorization header

  • You must send the stream-auth-type header set to anonymous

For security reasons, only a small subset of the API endpoints will be available to anonymous users.

Websocket

Copied!

Stream Chat uses Websocket connections to propagate chat events to all connected clients in real-time. Websockets are only used by Chat API servers to push events to users, you do not need them server-side.

Your Chat application should create a websocket connection per each user and wait until such connection is established before doing any other API call.

Websocket and Authentication

Copied!

Websocket connections must include authentication information; since it is not possible to send HTTP headers or a request body; such information must be included as query parameters:

Query parameter

Value

Description

stream-auth-type

jwt

Same as Stream-Auth-Type header

authorization

<token>

Same as Authorization header

Websocket and User Data

Copied!

Websocket connection must include the full information for the current user as well; the API endpoint will ensure that such user exists and will update it if necessary.

For information about request payload please see Connect Endpoint

Websocket Hello Event

Copied!

When the websocket connection is created with valid credentials and user payload; you will receive an event which includes fundamental information for later user of chat. Such message includes:

  • Current user's information including unread counts, the list of muted users and banned status

  • The connection_id for this session; you should store this, some API endpoints requires this parameter to be provided

Websocket Health-check events

Copied!

After the websocket connection is correctly established, the client will receive health-checks messages periodically. Your Chat client should make sure that such health-check event is received not later than 30 seconds ago; if that's not the case you should close and retry connecting.

Websocket and retries

Copied!

Unlike REST API calls, websocket connections are long-lived and might get closed due to internet connection errors. The recommended approach is to monitor internet connection, websocket close and error events and always retry to connect when a network issue causes the connection to break.

Websocket and Precondition Errors

Copied!

If you provide invalid authentication information or invalid data payload, an error message will be sent to the client and the connection will be closed with a status 1000 Normal Closure immediately after.

You can inspect the error message to gather more information about the failure and use that to decide what to do next. Error messages are JSON encoded and have the same schema as the ones from REST API endpoints.

When the connection is closed with such status you should not blindly retry to create the connection as it will almost certainly fail again with the same error. {

Websocket Events

Copied!

Once the websocket is created, you can move on and subscribe the user to channels either by using the Query Channels API endpoint or the Get Or Create Channel . From that point on, you will receive events related to all channels the user is watching (ie. messages from other users, typing events, mark read events, ...).

Websocket Notification Events

Copied!

You should expect the websocket connection to receive events that are not related to channels that the user is watching with the current websocket connection.

product:chat

Copied!

Ban user

Copied!
POST /moderation/ban

Request Body Schema

Copied!
Name
Type
Description
target_user_id
* string

Target user ID

ID of user to ban

timeout
integer

Timeout

Timeout of ban in minutes. User will be unbanned after this period of time

reason
string

Reason

Ban reason

channel_cid
string

Channel CID

Channel CID to ban user in eg. messaging:123

shadow
boolean

Shadow

Whether to perform shadow ban or not

ip_ban
boolean

IP ban

Whether to perform IP ban or not

banned_by_id
string

Banned by ID

User ID who issued a ban

banned_by
UserRequest

Banned by

User who issued a ban

user_id
string
user
UserRequest

Responses

Copied!
201 - Successful response
400 - Bad request
429 - Too many requests

Batch unread counts

Copied!
POST /unread_batch

Request Body Schema

Copied!
Name
Type
Description
user_ids
* string[]

<=100

Responses

Copied!
201 - Successful response
400 - Bad request
429 - Too many requests

Block user

Copied!
POST /users/block

Request Body Schema

Copied!
Name
Type
Description
blocked_user_id
* string

BlockedUserID

User id to block

user_id
string
user
UserRequest

Responses

Copied!
201 - Successful response
400 - Bad request
429 - Too many requests

Cast vote

Copied!
POST /messages/{message_id}/polls/{poll_id}/vote

Parameters

Copied!
Name
Type
Description
message_id
string
poll_id
string

string

Poll ID

Request Body Schema

Copied!
Name
Type
Description
vote
VoteData

VoteData

Vote data

user_id
string
user
UserRequest

Responses

Copied!
201 - Successful response
400 - Bad request
429 - Too many requests

Check External Storage

Copied!
GET /external_storage/{name}/check

Parameters

Copied!
Name
Type
Description
name
string

Responses

Copied!
200 - Successful response
400 - Bad request
429 - Too many requests

Check push

Copied!
POST /check_push

Request Body Schema

Copied!
Name
Type
Description
message_id
string

Message ID

Message ID to send push notification for

apn_template
string

APN template

Push message template for APN

Push Templates
firebase_template
string

Firebase template

Push message template for Firebase

Push Templates
firebase_data_template
string

Firebase data template

Push message data template for Firebase

Push Templates
skip_devices
boolean

Skip devices

Don't require existing devices to render templates

push_provider_type
string

Type of push provider

Push provider type

allowed values:

  • firebase
  • apn
  • huawei
  • xiaomi

push_provider_name
string

Name of push provider

Name of push provider

user_id
string
user
UserRequest

Responses

Copied!
201 - Successful response
400 - Bad request
429 - Too many requests

Check SNS

Copied!
POST /check_sns

Request Body Schema

Copied!
Name
Type
Description
sns_topic_arn
string

SNS Topic ARN

AWS SNS topic ARN

sns_key
string

SNS key

AWS SNS access key

sns_secret
string

SNS secret

AWS SNS key secret

Responses

Copied!
201 - Successful response
400 - Bad request
429 - Too many requests

Check SQS

Copied!
POST /check_sqs

Request Body Schema

Copied!
Name
Type
Description
sqs_url
string

SQS URL

AWS SQS endpoint URL

sqs_key
string

SQS key

AWS SQS access key

sqs_secret
string

SQS secret

AWS SQS key secret

Responses

Copied!
201 - Successful response
400 - Bad request
429 - Too many requests

Commit message

Copied!
POST /messages/{id}/commit

Parameters

Copied!
Name
Type
Description
id
string

Responses

Copied!
201 - Successful response
400 - Bad request
429 - Too many requests

Create a call

Copied!
POST /channels/{type}/{id}/call

Parameters

Copied!
Name
Type
Description
type
string
id
string

Request Body Schema

Copied!
Name
Type
Description
type
* string

allowed values:

  • audio
  • video

id
* string
options
object
user_id
string
user
UserRequest

Responses

Copied!
201 - Successful response
400 - Bad request
429 - Too many requests

Create block list

Copied!
POST /blocklists

Request Body Schema

Copied!
Name
Type
Description
name
* string

Name

Block list name

words
* string[]

Words

List of words to block

>=1

type
string

Type

Block list type.

allowed values:

  • regex
  • domain
  • email
  • word

Responses

Copied!
201 - Successful response
400 - Bad request
429 - Too many requests

Create channel type

Copied!
POST /channeltypes

Request Body Schema

Copied!
Name
Type
Description
name
* string

Name

Channel type name

typing_events
boolean

Typing events

Typing events support

read_events
boolean

Read events

Read events support

connect_events
boolean

Connect events

Connect events support

reactions
boolean

Reactions

Enables message reactions

replies
boolean

Replies

Enables message replies (threads)

search
boolean

Search

Enables message search

mutes
boolean

Mutes

Enables mutes

uploads
boolean

Uploads

Enables file uploads

url_enrichment
boolean

URL enrichment

Enables URL enrichment

custom_events
boolean

Custom events

Enables custom events

push_notifications
boolean

Push notifications

Enables push notifications

mark_messages_pending
boolean

Mark messages pending

Marks messages as pending by default

polls
boolean

Polls

Enables polls

message_retention
string
max_message_length
* integer

Maximum message length

Number of maximum message characters

automod
* string

Auto moderation

Enables automatic message moderation

allowed values:

  • disabled
  • simple
  • AI

automod_behavior
* string

Auto moderation behavior

Sets behavior of automatic moderation

allowed values:

  • flag
  • block

commands
string[]

Commands

List of commands that channel supports

permissions
PolicyRequest[]

Permissions

List of permissions for the channel type

grants
object
blocklist
string

Blocklist

Name of the blocklist to use

blocklist_behavior
string

Blocklist behavior

Sets behavior of blocklist

allowed values:

  • flag
  • block
  • shadow_block

blocklists
BlockListOptions[]

Responses

Copied!
201 - Successful response
400 - Bad request
429 - Too many requests

Create command

Copied!
POST /commands

Request Body Schema

Copied!
Name
Type
Description
name
* string

Name

Unique command name

description
* string

Description

Description, shown in commands auto-completion

args
string

Arguments

Arguments help text, shown in commands auto-completion

set
string

Set

Set name used for grouping commands

Responses

Copied!
201 - Successful response
400 - Bad request
429 - Too many requests

Create device

Copied!