List changed inbox threads

Use this endpoint to follow which inbox threads changed without re-listing the inbox. It returns threads in the order they were changed, earliest change first, and you read it forward with a cursor. A thread appears each time it changes: a new message, inbound or outbound, including one synced late; marking it read or unread; a meeting intent change; an owner change; its deletion from the inbox. Changing a thread’s category alone does not return it; the category on each item, and hasMeetingIntent, which also follows the category, are the thread’s values at the time of the read. Each item carries the thread’s latest message, so you can tell a contact’s reply from your own send. You see the same threads as in the thread list.

lastActivityDate is the date of the message that last moved the thread, at the same 10 ms precision as the message dates; nothing else moves it (not category, meeting intent, viewed, owner or delete changes). For a thread whose latest message is an email or a LinkedIn message, it equals lastMessage.date; it can be later when the latest message is an SMS, which lastMessage does not carry.

isDeleted true means the thread was deleted; the change reported is the deletion, and GET /v3/inbox/threads/{id} answers 404 for it. A thread removed together with its contact, its sequence enrolment or its team is not reported; GET /v3/inbox/threads/{id} answering 404 is how you learn of it.

A change of who may see a thread is not a change of the thread: a thread moved to another owner is not reported to a reader who saw it only as the previous owner’s, and threads that become visible to you through a sequence or contact owner change are not returned until they change again. After a change of your role, of ownership or of your team, read again with since.

Start a read in one of three ways: pass the cursor from a previous page; pass since to start from the threads whose last activity is at or after that moment (at most 30 days ago); or pass neither to start from the last 30 days. Pass cursor or since, not both. A read started from since or with no parameters first returns the threads that moved in that window, oldest first, by the moment the thread moved, deleted threads excluded: a thread deleted before the read is not listed. The window lists only live threads: a thread you hold whose last activity is at or after the window’s start and that the window does not return was deleted or is no longer visible to you, and for a thread whose last activity is before the window’s start the window says nothing (only a message moves lastActivityDate, so a deletion does not bring a thread into the window). Deletions are reported only by the changes you read by cursor (isDeleted), so a read started again does not report the deletions made since your last cursor; confirm a thread you hold with GET /v3/inbox/threads/{id}, which answers 404 for a deleted one. It then continues with the changes made since the read began, by cursor like any later read: a thread written, moved or deleted while the window was being read arrives there, whatever its last activity, so it can appear twice.

The cursor is a position in the sequence of changes, not a time. Keep calling with the returned cursor while hasMore is true; read until hasMore is false, not until a page is empty, because a page can be empty with hasMore true: while the read passes threads it does not return (threads you cannot see, or deleted threads in the window), and when it reaches the end of the window, as when the window’s last thread was deleted while it was being read. When hasMore is false, store the cursor and call again later: the next call returns every change made after the page was read, and none is skipped. An empty page with hasMore false returns a cursor at the feed’s current position, never behind the one you passed. A change becomes readable once every write in progress before it has finished, so a long-running write anywhere in Reply can hold the feed back for every team until it completes; nothing is lost while it waits. Delivery is at least once: a thread can come back after a cursor that already covered it, so process each item as the thread’s current state, keyed on threadId.

A cursor ahead of the feed’s current position (as after a restore of the service’s data), or a since older than 30 days, is refused with 400 and the code inboxThread.changeWindowExpired; start again with since or with no parameters.