Skip to main content
GET
List inbox threads

Authorizations

X-API-Key
string
header
required

Query Parameters

view
string
default:all
Pattern: ^(all|unlabelled|needs_approval|out_of_office|bounces|reminders|sent|all_mail)$
unread_only
boolean
default:false
reply_state
enum<string> | null

Whether the contact's latest reply has had an answer from us.

A filter over the working inbox, where every conversation is one the contact answered. REPLIED: an answer of ours went out after their latest reply, written by a person or by the agent. A LinkedIn reply queued for the browser counts once nothing waits on a person's approval for it (a person sent it, or its task was approved); one still waiting on Tasks, a failed one and a forward to somebody else do not. NOT_REPLIED: their latest reply is still the last word. Only a genuine reply asks for an answer, so an auto-reply or a bounce arriving after our answer leaves a conversation REPLIED, and a thread whose only inbound mail is automatic is no conversation at all: the inbox does not list it, so neither state does.

Available options:
replied,
not_replied
sequence_id
string<uuid> | null
mailbox_id
string<uuid> | null
sender_profile_id
string<uuid> | null
sequence_id__not
string<uuid>[] | null
Maximum array length: 100
mailbox_id__not
string<uuid>[] | null
Maximum array length: 100
sender_profile_id__not
string<uuid>[] | null
Maximum array length: 100
label_id
string<uuid> | null
channel
enum<string> | null

Which surface a conversation happens on.

Threads are contact-scoped, not channel-scoped, so this says how a thread is REACHED rather than partitioning the inbox: a reply arrives, is classified and stops the cadence identically either way, and only the send path differs.

Available options:
email,
linkedin
last_message_at__after
string<date-time> | null
last_message_at__before
string<date-time> | null
sort
enum<string>
default:newest

The order a working inbox is read in.

NEWEST is the default and what every mail client does. LONGEST_WAITING is the one a sales team actually triages by: a reply that came in on Monday and still has no answer on Thursday is the most expensive thing in the list, and newest-first buries it under everything that has arrived since. Smartlead builds its whole SLA view on this ordering, and we had no way to reach it: the list was newest-first with no alternative.

Deliberately two named READINGS rather than a generic field+direction pair. "Longest waiting" is not last_message_at asc: an expired snooze lifts a thread to its wake-up time, so both orderings sort the same computed instant, and exposing the raw column would let a caller ask for an order that disagrees with the one the list actually uses.

Available options:
newest,
longest_waiting,
positives_first,
sequence
search
string | null
Maximum string length: 255
limit
integer
default:50
Required range: 1 <= x <= 100
offset
integer
default:0
Required range: x >= 0

Response

Successful Response

threads
ThreadReadSchema · object[]
required
total
integer
required