# HXP Threads and Actions
> Source: /hxp/overview
> What HXP exposes today for conversations, events, actions, and delegated assistants

HXP owns guest conversations, Inbox attention, team work, approvals, and execution receipts. A conversation keeps the guest, stay, audience, and action together. Core, HMS, and connected providers remain authoritative for their operational records and outcomes.

<Info>
  HXP's new [machine integration contract](/hxp/machine-integrations) uses organization-owned WorkOS API keys with explicit capabilities, workspaces, and audiences. The production service is deployed and enabled; follow the guide for organization setup and the remaining connected verification status. Operator HTTP APIs and delegated MCP remain separate authentication surfaces.
</Info>

## Choose the right surface [#choose-the-right-surface]

| Need | Implemented surface | Third-party availability |
| --- | --- | --- |
| Read eligible guest comments and Actions | Organization-key `/api/external/v1/messaging` | Enabled production endpoint; requires a verified organization setup and an explicit HXP grant |
| Read personal Inbox | Session-authenticated operator HTTP API | First-party HXP only |
| Listen for changes | Cursor-based JSON event polling in the machine API | Requires events plus resource-read permissions; no push subscription |
| Claim, complete or cancel an Action | Explicit M2M commands with version checks and receipts | Integrations claim unowned work and update their own work; no arbitrary status patch |
| Read authorized guest evidence from an assistant | Operator MCP `read_thread` | Requires Journey-managed OAuth host qualification and deployment activation |
| Start, inspect, or cancel bounded assistant work | Operator MCP `start_task`, `task_status`, `cancel_task` | Same activation requirement; not arbitrary Action status editing |
| Enter from Slack | Signed, installation-bound app mentions and identity linking | Configured channel integration; not a general message mirror |
| Send guest SMS and receive delivery status | Configured SMS provider, consent, exact approval, signed callbacks | Provider integration; not a public messaging API |

## Deployment status [#deployment-status]

The M2M endpoint was enabled from commit `974da1f9ae67dbf040029bcc0d7c64cc2fd6c1bb` on September 19, 2026. See [machine integration release status](/hxp/machine-integrations) for the connected verification boundary. This does not activate operator MCP.

This reference was checked against HXP commit `6d470122c3d206723a51fca81768206757f5a447` on **September 19, 2026**. On that date, the production protected-resource discovery endpoint and MCP POST endpoint both returned HTTP `503`; MCP reported **“Operator MCP is not configured.”** Implementation is not evidence of activation. Recheck discovery and complete an authorized connected test before onboarding an integration.

The base origin for these HXP routes is `https://v3.hxp.journey.com`. It is separate from the Core API base URLs elsewhere in these docs. HXP JSON envelopes and authentication also differ.

<CardGroup cols={2}>
  <Card title="API keys and M2M" icon="key" href="/hxp/machine-integrations">Third-party credentials, polling and Action transitions.</Card>
  <Card title="Authentication and access" icon="shield" href="/hxp/authentication">Sessions, delegated OAuth, scopes, and tenant boundaries.</Card>
  <Card title="Threads and listening" icon="messages-square" href="/hxp/threads-and-events">Read contracts, event cursors, and channel limitations.</Card>
  <Card title="Actions and status changes" icon="list-checks" href="/hxp/actions">Ownership, transitions, evidence, conflicts, and receipts.</Card>
  <Card title="Operator MCP" icon="plug" href="/hxp/operator-mcp">The five implemented tools and conditional integration examples.</Card>
</CardGroup>

## What makes HXP different [#what-makes-hxp-different]

- **Guest context stays attached.** Records identify the organization, workspace scope, guest, optional stay, and staff or team audience. A thread is read by guest ID; a reply identifies its parent message.
- **Attention is personal.** Inbox items represent mentions, replies, assignments, and followed-thread updates for the current actor. Reading an Inbox item does not complete the associated work.
- **Actions are accountable.** Ownership, due time, completion evidence, version, and receipt are distinct fields. A reaction or message saying “done” is not an Action transition.
- **AI evidence is filtered.** MCP thread reads exclude sensitive comments and private AI history. Current permissions and source validity are checked again when work runs.
- **Guest delivery has separate proof.** Approval, provider submission, and delivery confirmation are different states. Completing an HXP Action does not establish that a benefit was redeemed, a booking changed, or a guest message arrived.

## Planning a third-party integration [#planning-a-third-party-integration]

For a backend that listens and updates Actions, use the [M2M guide](/hxp/machine-integrations). For a qualified assistant, use the separate [MCP onboarding requirements](/hxp/operator-mcp). Neither surface accepts exported operator session cookies or interchangeable Core credentials.

The M2M release is bounded to HXP-owned comments and Actions. Core, HMS, payments, guest delivery and AI approvals keep their existing authority and integration contracts. Follow the activation status on the M2M guide before onboarding a production consumer.