Channels: One Session Model Across Every Medium

Feather runs every customer interaction through the same conversation model, regardless of how the customer reaches you. A conversation is classified by a few server-assigned facts that together describe where and how it runs.

​

How a conversation is classified

You don’t set channel or surface directly — Feather assigns them based on how the conversation is created. Creating one over the API (POST /v1/conversations) always yields a chat conversation on the direct_api surface.

---

​

Where each channel is created

Each channel has its own entry point, but they all produce the same conversation object with the same turns, transcript, analytics, and HITL behavior.

---

​

Identity across channels

Every conversation resolves to an end_user_id. How that happens depends on what you provide at creation:

• end_user_id — reference a known end user directly.
• org_external_end_user_id — pass your own stable identifier (a customer ID, or a persisted anonymous browser token). Feather get-or-creates an end user and, when possible, bridges it to the same person’s existing email or phone identity.
• Nothing — Feather resolves the authenticated caller as the end user.

Because a phone number, an email address, and your own customer ID can all resolve to the same end user, an assistant gets a unified view of that person across channels — a customer who texts today and emails next week shares one history and one memory.

​

Thread keys

Within a channel, external_id distinguishes concurrent threads for the same user. Reusing a value resumes that thread; a new value opens another. external_id is unique per organization, which also makes conversation creation idempotent under retries.

---

​

Next steps