Skip to main content
POST
Reply in a thread

Authorizations

Authorization
string
header
required

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Path Parameters

thread_id
string<uuid>
required

Body

multipart/form-data
body_text
string
required
Required string length: 1 - 100000
bcc
string | null
Maximum string length: 2000
cc
string | null
Maximum string length: 2000
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
files
file[] | null
include_history
boolean
default:false
mailbox_id
string<uuid> | null
omit_signature
boolean
default:false
reply_to_message_id
string<uuid> | null
subject
string | null
Maximum string length: 998
to
string | null
Maximum string length: 2000

Response

Successful Response

attachments
AttachmentReadSchema · object[]
required
body_text
string
required
bounce_severity
enum<string> | null
required

NEW-A: hard vs soft severity of a BOUNCE message.

Only HARD marks the contact bounced (§29's condition, the enrolment analytics bounce rate, §57's per-message outcome) — SOFT still fills the Bounces view and never looks like a reply, but the address may still be reachable, so the cadence is left alone.

Available options:
hard,
soft
channel
enum<string>
required

INB-25: this message's own channel. Threads merge channels, so the reader captions each message by what it actually is — a LinkedIn DM involves no email addresses.

Available options:
email,
linkedin
direction
enum<string>
required
Available options:
outbound,
inbound
from_address
string
required
id
string<uuid>
required
mailbox_id
string<uuid> | null
required
message_class
enum<string> | null
required

What an inbound message turned out to be.

REPLY stops the cadence; BOUNCE (a DSN) marks the contact bounced and never looks like a reply; OUT_OF_OFFICE never stops anything and defers the cadence to the stated return when one is parsed.

Available options:
reply,
bounce,
out_of_office
send_state
enum<string>
required

Whether a message has actually left.

Only meaningful on LinkedIn. An email row is written after the provider accepted it, so it is SENT the moment it exists; a LinkedIn reply is written when it is QUEUED, and cannot become SENT until the customer's own browser has delivered it. Showing the two the same way would have the product assert a delivery it has no evidence for.

Available options:
sent,
queued,
failed
sent_at
string<date-time>
required
subject
string
required
thread_id
string<uuid>
required
to_address
string
required
body_html
string | null

INB-09: the sender's raw HTML part; sanitise before rendering.

sequence_id
string<uuid> | null

§78: the sequence this message was sent from, when it came from one.

step_id
string<uuid> | null

§78: which step sent this message — carried per-message (not just on the thread) because a contact re-enrolled in a different sequence keeps their earlier messages' own sequence/step, distinct from the thread's current one.