A single conversation

GET returns a single Conversation or an HTTP 404 status if no conversation exists for the given conversation ID.

PUT creates or updates a conversation.


Example url: /v1/q3k1pa9d/conversations/order_fc_491731

Setting conversation data

You can use a PUT request method to create a conversation or to update (a subset of) conversation attributes.

To update conversation details, you only need to send the subset of fields you want to update. In that respect, even though you update a conversation with an HTTP PUT request method, the user update acts similar to an HTTP PATCH request method.

1type ConversationId = string;
2type UnixMilliseconds = number;
4type RequestBody = {
5 participants?: Array<string>,
6 subject?: string | null,
7 welcomeMessages?: Array<string> | null,
8 custom?: Map<string, string> | null,
9 photoUrl?: string | null

PUT merges data with existing data, if any. For example, you cannot remove participants from a conversation by PUTing a list of participants that excludes some existing participants. If you want to remove participants from a conversation, use the Participation endpoint.

Getting created conversations

After you successfully create or update a conversation, you can fetch it back with a GET REST call.

1type ConversationId = string;
2type UnixMilliseconds = number;
4type Conversation = {
5 id: ConversationId;
6 subject: string | null;
7 photoUrl: string | null;
8 welcomeMessages: string[] | null;
9 custom: { [name: string]: string };
10 lastMessage: Message | null;
11 participants: {
12 [id: UserId]: { access: 'ReadWrite' | 'Read'; notify: boolean };
13 };
14 createdAt: UnixMilliseconds;
15 topicId: string;

Deleting a conversation

Use this endpoint to irrevocably delete data for a certain conversationId. All the data and metadata linked to the conversation will be deleted. Here is the list of things that will happen:

  1. All messages in the conversation will be deleted.
  2. Participants will not be a part of the conversation anymore.
  3. All the conversation metadata will be erased.
  4. Active UIs will display a "Chat not found" screen (which is localized).
  5. The conversation gets removed from all (former) participants' Inbox feeds.

NOTE: Users that take part in the conversation WILL NOT be deleted.


Marking a conversation as read

This endpoint is used to mark a conversation as read for a specific user. Doing so will also mark any messages within the conversation as read by that user.

You must send an empty request payload when marking a conversation as read.


Listing all conversations in the application

This lists all conversations ever created in your TalkJS application. This request is paginated as explained here. The response has a data field with an array of Conversation objects as described above.

2 "data": Array<Conversation>


Ordering is available since API version 2021-02-09

Default order in versions before 2021-02-09 is createdAt DESC and cannot be changed

By default, conversations are returned in the order of the last activity in them, latest first. You can change the order by using orderBy and orderDirection query parameters. Conversations can either be sorted on a creation date or on the last activity in that conversation. Ordering conversations by the creation date can be useful when you want stable sorting.

Following values are accepted in orderBy query parameter:

  • lastActivity (default): sort by last activity timestamp
  • createdAt: sort by date of creation

Following values are accepted in orderDirection query parameter:

  • DESC (default): descending order
  • ASC: ascending order


offsetTs is available since API version 2021-02-09

Conversations can be paginated, as any other listing handle.

Using startingAfter requires passing in a conversation ID, whereby results will start with the conversation right after the selected one in the current sort order. It works with all currently supported sorting options.

Another option is to use offsetTs which accepts a timestamp and offsets the results according to the sort order. This might be more useful when used in conjunction with lastActivity sorting since conversations can move to the front of the list as new messages come, and using one of the conversations as a pointer can yield unexpected results.

Filtering conversations

By the last message's timestamp

It is possible to filter conversations by when the last message was sent to the conversation using the lastMessageBefore and lastMessageAfter filters.

lastMessageBefore and lastMessageAfter should be Unix timestamps expressed in milliseconds.

For example, the following query string parameters get conversations where the last message was sent between the Unix timestamps 1701700000000 and 1702000000000:


By custom filters

TalkJS also supports filtering by various fields. The filter interface is precisely the same as the JavaScript SDK's Conversation Filter. In order to filter conversations by a custom filter you need to URLencoded the JSON formatted filter.

You can use your favorite programming language to generate the conversation filter in the required JSON structure.

NodeJS example:

1const filter = { custom: { category: ['==', 'shoes'] } };
2const encodedFilter = encodeURIComponent(JSON.stringify(filter));
3const res = await fetch(
4 `${appId}/conversations?filter=${encodedFilter}`
6const conversations = await res.json();

Filters can be combined together with limits and cursors.


6// URL encoded version of the filter {"custom":{"category":["==","shoes"]}

Filtering by user

The Users resource lets you list the conversations a specific user is a part of.