List inbox threads
Newest-first by default, unless search is set. Then it is ranked by relevance, most useful match first, and sort is ignored. sort=longest_waiting reads the same list from the other end, oldest activity first, which is how a reply that has been sitting unanswered for three days gets to the top. Auto-replies and bounces live in their own views; unlabelled is the work queue: real threads nobody and no classifier has described yet. search runs full-text over every message plus the contact's name and address. channel and the last_message_at__after / last_message_at__before bounds narrow the list; both bounds are inclusive. The working views (all, unlabelled, needs_approval) list only conversations the contact wrote into: a send nobody answered is not in the inbox. all and unlabelled list only those still waiting on us: a reply with no answer yet, an unread conversation, a reminder that went off, or an answer of ours that went three business days unanswered (came_back, returns_at) when the verdict on their latest reply does not say the conversation is over. Once we answer, a conversation moves out and stays in sent; one marked done (is_done) stays out until a new message reaches us. A search or a label_id reads every conversation the contact wrote into, waiting or not. Each row's listed_at is the moment it sorts by. out_of_office, bounces and reminders list what a machine wrote or the person snoozed. sent lists every conversation something of ours went out in, a sequence step or a reply, on email or LinkedIn, answered or not and whatever became of it since; a LinkedIn reply still queued for the browser, or one that failed, has not gone out. A send nobody answered never lights the unread badge. Each row's contact_replied says whether the contact has written back. reply_state=replied keeps the conversations we answered after the contact's latest reply, by a person or the agent; reply_state=not_replied keeps the ones whose latest reply is still the last word. all_mail lists every conversation, whatever became of it: the place a conversation marked done is found.
Request
- Base URL: https://api.getoneprofile.ai (the document declares no server; this is the origin it was published from)
- URL: https://api.getoneprofile.ai/inbox/threads/
- Auth: one of:
- API key in header X-API-Key
- HTTP bearer
Query parameters
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.
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.
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.
Response
Successful Response
Changes
No recorded changes to this operation across all 1 revision of this API.