> ## Documentation Index
> Fetch the complete documentation index at: https://docs.open.cx/llms.txt
> Use this file to discover all available pages before exploring further.
# Connect overview
> In-app chat between buyers, sellers, and couriers — with an AI in every conversation that answers, translates, and calls in your team when needed.
**Connect** puts the parties of a transaction — buyer and seller, customer and merchant, and the courier in between — into one conversation: scoped to a single order, booking, or listing, rendered inside your own apps, and supervised by the same AI agent that already runs your support.
One API call when the transaction starts. Everything else — who can talk to whom, translation between them, answering "where's my order?" before a human ever types, closing the thread when the transaction completes — is handled for you.
**[TicketSwap](https://www.open.cx/customer-stories/ticketswap)** mediates buyer↔seller conversations for **19 million fans** with Connect — the AI Supervisor sits between the two sides of every resale, answers the questions neither party should carry, and steps in before a dispute becomes a ticket. Read the [customer story](https://www.open.cx/customer-stories/ticketswap).
```mermaid theme={"dark"}
flowchart LR
subgraph T["Thread · order_84421"]
AI(("AI Supervisor"))
C["Customer"] <--> AI
M["Merchant"] <--> AI
D["Courier"] <--> AI
C <-.-> M
C <-.-> D
end
AI -- "escalation" --> H["Your support inbox"]
```
## Why teams pick Connect over a chat SDK
Chat infrastructure vendors sell you channels. You still build the hard part yourself: creating a channel per order, inviting the right people at the right moment, tearing it down after delivery, wiring moderation, bolting a helpdesk on the side — and the conversations themselves stay dumb. Nobody answers, nobody translates, nobody notices the customer is about to churn.
Connect ships the whole transaction workflow as the product:
| | Chat infrastructure | OpenCX Connect |
| --------------------- | -------------------------------------------- | --------------------------------------------------------- |
| Conversation model | Channels you orchestrate per order, per pair | One **thread** per transaction, roles built in |
| Lifecycle | You freeze/delete channels from your backend | Follows the transaction status automatically |
| Who talks to whom | Separate 1:1 channels you manage | **Lanes** with per-role visibility |
| Translation | Paid add-on, per-message API calls | Built in, per participant's language |
| "Where's my order?" | Merchant or courier types the answer | AI answers instantly from your Actions |
| Unanswered messages | Nothing happens | AI nudges, then covers for the silent party |
| Escalation to support | Separate desk product + integration work | Native — a thread escalates into a normal OpenCX session |
| Safety | Wordlist filters you configure | AI moderation: PII masking, abuse, off-platform detection |
## The three pieces
A transaction-scoped conversation with roles, lanes, and a lifecycle that mirrors the transaction — open, locked, archived.
Watches every lane. Answers instantly, translates live, nudges silent parties, masks unsafe content, escalates to your team.
A prebuilt thread component for your customer, merchant, and courier apps — or raw REST + webhooks if you own the UI.
## What teams run on Connect
The same thread model fits any transaction with two or three parties — use the roles that match your marketplace and skip the ones that don't:
* **Marketplace resale** — buyer↔seller mediation on every listing: "is it still available?", payment-safety nudges, dispute de-escalation, and an AI that masks off-platform contact attempts. (This is TicketSwap's shape: two roles, no courier.)
* **On-demand delivery** — the three-touchpoint order: customer↔merchant for "no onions please", customer↔courier for "gate code is 4411", and the AI absorbing order status, ETAs, and refund questions from your Knowledge and [Actions](/actions/introduction) before anyone is interrupted.
* **Bookings and services** — guest↔host, client↔provider: pre-appointment questions, reschedules answered from your calendar Actions, and post-service issues caught while they're still small.
Whatever the shape, **your support team stays in one inbox.** When a thread needs a human, it escalates into a standard OpenCX [session](/api-reference/chat-sessions/index) with the full thread context attached — same inbox, same handoff rules, same analytics as every other channel.
## Where to next
Order chat live in your app in about fifteen minutes.
Threads, participants, messages, tokens — the full REST surface.