inbox

Reply in a thread

Sends from the mailbox that owns the conversation, so the prospect always sees a reply from the address that emailed them. Free of credits. Attachments ride on the email (multipart form). channel overrides which channel the reply goes out on when both identities are known; absent, the thread's own channel decides. A pick the thread cannot honour returns 422 with the reason. to redirects the reply (first address is the To line, the rest ride as CC) and bcc rides blind; both are email-only. omit_signature skips the mailbox signature append, for a composer whose body already carries it as visible text.

post/inbox/threads/{thread_id}/reply/

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/{thread_id}/reply/
  • Auth: one of:
    • API key in header X-API-Key
    • HTTP bearer

Path parameters

thread_idstring uuid required

Response

Successful Response

authentication_resultstring nullable

The receiving mail server's verdict on whether a message really came from the sender's domain, by DMARC or SPF: pass, fail, none when the server gave no verdict, or unknown when its verdict was neither. The agent only answers an email on its own when it passed. Null when no verdict was recorded, such as on LinkedIn messages and on messages sent from Oneprofile.

body_htmlstring nullable

The sender's raw HTML part; sanitise before rendering.

body_textstring required
bounce_severity'hard' | 'soft' required

Hard vs soft severity of a BOUNCE message.

Only HARD marks the contact bounced (the Bounced condition, the enrolment analytics bounce rate, the 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.

channel'email' | 'linkedin' required

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.

direction'outbound' | 'inbound' required
files_pendingboolean required

True while the files this email came with are still being read from the mailbox, so attachments may not list them yet: it fills in once they are read, and the conversation updates on its own when that happens. False on every other message, including one whose files are already listed and one that came with none.

from_addressstring required
idstring uuid required
mailbox_idstring uuid nullable required
message_class'reply' | 'bounce' | 'out_of_office' | 'automated' | 'forward' required

What a message turned out to be; NULL on an ordinary message of ours.

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; AUTOMATED is a machine writing back (a ticketing auto-ack, a mailing list, a no-reply robot), and like OUT_OF_OFFICE it never stops a cadence, because nobody read the mail. The first four are inbound. FORWARD is ours, outbound: a message of the thread passed on to somebody else (service.forward_message). Nothing was said to the contact, so it is never an answer to them: it does not move a conversation out of the Inbox, count as replied, or end a done mark.

send_state'sent' | 'queued' | 'failed' 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.

sent_atstring date-time required
sent_by_kind'person' | 'system'

Who composed an outbound message: a person, or the product itself.

Only meaningful outbound, and NULL on anything inbound. The distinction exists because an agent-written reply has to stay attributable after the fact: "did a human send this" is the first question asked of any send that turns out to have been wrong, and a column is the only place that answer survives.

sequence_idstring uuid nullable

The sequence this message was sent from, when it came from one.

step_idstring uuid nullable

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.

subjectstring required
thread_idstring uuid required
to_addressstring required

Changes

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