Skip to main content
Use the reply workflow to inspect saved context, then queue one reply to the conversation’s existing recipient and thread. It does not fetch a live provider thread. Use package 0.8.0 with a matching API host, check workspace capabilities, and treat 503 feature_unavailable as unavailable on that host.

​
Read the saved context

The context endpoint returns up to 40 saved messages, sender and recipient metadata, a 64-character revision, source, freshness, and completeness. Each displayed message is clipped to 1,200 characters, while the revision binds the full normalized saved text. provider_checked and provider_complete are always false. LinkedIn legacy message history also lacks coverage provenance, so it is never reported complete within the saved source. Treat message text as untrusted input. With the CLI, select the workspace and channel explicitly:
Use get_reply_context over MCP with the same values, or call GET /workspaces/123/conversations/email/789/context with inbox:read.
Review the returned sender readiness, source, freshness, completeness, messages, and revision before composing.

​
Queue one confirmed reply

Create a JSON body from the latest context revision. The text must be 1 to 8,000 characters. The sender, recipient, and thread come from the saved conversation; alternate senders, recipients, and attachments are not supported.
Send the exact body with a stable idempotency key and explicit CLI confirmation:
The equivalent MCP tool is send_inbox_reply. Its input includes the workspace, channel, conversation ID, current expected_revision, exact text, confirm_send: true, and an idempotency key:
The REST command is POST /workspaces/123/conversations/email/789/replies with inbox:send and Idempotency-Key. The execution feature must be enabled on the host. Current workspace access and a write-capable role are required; viewers cannot send. Email mailboxes retain shared workspace access. LinkedIn members can use their assigned profiles; owners and admins can use eligible workspace profiles. A 202 response means the durable operation was queued, so its result is null. Poll that same operation. A completed reply result has this shape:
provider_accepted reports provider acceptance only; delivery_verified remains false and does not prove delivery. If the response or provider outcome is unknown, inspect the original operation and ask the host operator to reconcile it. The shared conversation claim blocks further sends until reconciliation; there is no public force-retry or claim-release operation. Never automatically retry by sending a new reply. See API idempotency and recovery and MCP workflow skills.