Conversations
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
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;34type RequestBody = {5 participants?: Array<string>,6 subject?: string | null,7 welcomeMessages?: Array<string> | null,8 custom?: Map<string, string> | null,9 photoUrl?: string | null10}
1{2 "participants": ["123456", "654321"],3 "subject": "Black leather boots",4 "welcomeMessages": ["Hello there!", "I'm currently out of town, leave a message and I'll respond ASAP. :)"],5 "custom": {6 "productId": "454545"7 },8 "photoUrl": "https://example.com/productpictures/454545.png"9}
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.
After you successfully create or update a conversation, you can fetch it back with a GET REST call.
1type ConversationId = string;2type UnixMilliseconds = number;34type 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]: {13 access: 'ReadWrite' | 'Read';14 notify: boolean | 'MentionsOnly';15 isUnread: boolean;16 };17 };18 createdAt: UnixMilliseconds;19 topicId: string;20};
1{2 "createdAt": 1623926680929,3 "custom": {},4 "id": "87d70908d90cee5d12bd",5 "topicId": "customer_support",6 "lastMessage": {7 "attachment": null,8 "conversationId": "87d70908d90cee5d12bd",9 "createdAt": 1632919967033,10 "editedAt": null,11 "custom": {},12 "id": "msg_0UQbqdxnQWkoIw7Db7fZHK",13 "location": null,14 "origin": "web",15 "readBy": [],16 "senderId": "432156789",17 "text": "Hey, I'm in London",18 "type": "UserMessage",19 "referencedMessageId": null20 },21 "participants": {22 "123456789": {23 "access": "ReadWrite",24 "notify": true,25 "isUnread": true26 },27 "432156789": {28 "access": "ReadWrite",29 "notify": true,30 "isUnread": false31 }32 },33 "photoUrl": null,34 "subject": "Random conversation",35 "welcomeMessages": null36}
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:
- All messages in the conversation will be deleted.
- Participants will not be a part of the conversation anymore.
- All the conversation metadata will be erased.
- Active UIs will display a "Chat not found" screen (which is localized).
- The conversation gets removed from all (former) participants' Inbox feeds.
NOTE: Users that take part in the conversation WILL NOT be deleted.
This endpoint is used to mark a conversation as read or unread for a specific user.
Setting the isUnread
parameter to true
marks the conversation as unread; setting the isUnread
parameter
to false
marks the conversation as read, and omitting the isUnread
parameter, or setting it to null
does
not change the read/unread status of the conversation.
Marking a conversation as read will also mark any messages within the conversation as read by that user, but marking a conversation as unread will not change the read/unread status of any message within the conversation.
1{2 isUnread?: boolean | null,3}
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.
1{2 "data": Array<Conversation>3}
1{2 "data": [3 {4 "createdAt": 1623926680929,5 "custom": {},6 "id": "87d70908d90cee5d12bd",7 "lastMessage": {8 "attachment": null,9 "conversationId": "87d70908d90cee5d12bd",10 "createdAt": 1630326385720,11 "editedAt": null,12 "custom": {},13 "id": "msg_7HtvCJLjdZoRsYE2nCXp2n",14 "location": null,15 "origin": "web",16 "readBy": ["123456789"],17 "senderId": "432156789",18 "text": "it",19 "type": "UserMessage",20 "referencedMessageId": null21 },22 "participants": {23 "123456789": {24 "access": "ReadWrite",25 "notify": true26 },27 "432156789": {28 "access": "ReadWrite",29 "notify": true30 }31 },32 "photoUrl": null,33 "topicId": "customer_support",34 "subject": "Random conversation",35 "welcomeMessages": null36 },37 {38 ...39 }40 ]41}
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 timestampcreatedAt
: sort by date of creation
Following values are accepted in orderDirection
query parameter:
DESC
(default): descending orderASC
: ascending order
offsetTs
is available since API version2021-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.
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
:
1?lastMessageAfter=1701700000000&lastMessageBefore=1702000000000
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 `https://api.talkjs.com/v1/${appId}/conversations?filter=${encodedFilter}`5);6const conversations = await res.json();
Filters can be combined together with limits and cursors.
Examples
1GET https://api.talkjs.com/v1/{appId}/conversations2GET https://api.talkjs.com/v1/{appId}/conversations?lastMessageBefore=1521522849308&lastMessageAfter=14215228497323GET https://api.talkjs.com/v1/{appId}/conversations?limit=50&lastMessageAfter=14215228497324GET https://api.talkjs.com/v1/{appId}/conversations?startingAfter=c_2156// URL encoded version of the filter {"custom":{"category":["==","shoes"]}7GET https://api.talkjs.com/v1/{appId}/conversations?filter=%7B%22custom%22%3A%7B%22category%22%3A%5B%22%3D%3D%22%2C%22shoes%22%5D%7D%7D
The Users resource lets you list the conversations a specific user is a part of.
NOTE: This endpoint is deprecated. Please use the endpoint described in the previous section instead.
1{}