inbox

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.

get/inbox/threads/

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

viewstring
unread_onlyboolean
reply_state'replied' | 'not_replied'

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.

sequence_idstring uuid nullable
mailbox_idstring uuid nullable
sender_profile_idstring uuid nullable
sequence_id__notstring[] nullable
mailbox_id__notstring[] nullable
sender_profile_id__notstring[] nullable
label_idstring uuid nullable
channel'email' | 'linkedin'

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.

last_message_at__afterstring date-time nullable
last_message_at__beforestring date-time nullable
sort'newest' | 'longest_waiting' | 'positives_first' | 'sequence'

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.

searchstring nullable
limitinteger
offsetinteger

Response

Successful Response

totalinteger required

Changes

No recorded changes to this operation across all 1 revision of this API.