> ## Documentation Index
> Fetch the complete documentation index at: https://docs.minidesk.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Channels

> How you and your customers talk to each other. Everything lands in one inbox.

A **channel** is a two-way line between you and a customer. Requests come in on
it; replies go back out on it. Run all of them at once if you like. It makes no
difference to your team, because every channel feeds the same inbox.

Find them in the dashboard under **Channels**.

<CardGroup cols={3}>
  <Card title="Chat" icon="message" href="/channels/chat-widget">
    One script tag on your site. Works on any page.
  </Card>

  <Card title="Contact form" icon="clipboard" href="/channels/contact-form">
    A card you place inside your own contact page.
  </Card>

  <Card title="Email" icon="at" href="/channels/email">
    Forward your existing support address.
  </Card>
</CardGroup>

The API is a fourth way in. It does not appear on that screen because there is
nothing to configure. Any ticket created through
[the REST API](/api-reference/introduction) arrives with `source: "api"`.

## One of each kind

A workspace supports at most one chat widget and at most one contact form.
Email is one address.

If you need chat on two domains, use a single placement and list both domains
on it. Do not create a second placement.

## Picking one

|                  | Best for                                      | Setup                      |
| ---------------- | --------------------------------------------- | -------------------------- |
| **Chat**         | Questions while someone is using your product | One line of code           |
| **Contact form** | A contact page that should stay a page        | Two lines of code          |
| **Email**        | Customers who already write to you            | A forwarding rule, no code |

Email is where most workspaces start. The address already exists, and
customers already use it. Chat usually follows once you want to reach people
before they leave.

## What is the same everywhere

No matter which channel a conversation arrives on:

* It becomes a **ticket**, carrying a reference and a requester.
* Triage fills in a priority and a category if the message does not make them
  obvious.
* The language is detected, and your team can reply in it.
* The AI drafts a reply from your reference documents. It either suggests one
  or sends one, depending on your settings.

## Requesters, and what "verified" means

The requester is the person on the other end. Whether they are **verified**
comes down to who vouched for them. There are exactly two answers.

**Verified**: an API credential supplied an `external_id`. Someone holding a
key we issued vouched for this person from their own server.

**Unverified**: anything else. An address a visitor typed into chat, or a
value a web page asserted.

That line is drawn where it is because anything a page can claim without
proof, anyone with devtools open can claim too. Our JavaScript runs on your
visitor's machine, which makes it theirs, not ours.

Unverified is still useful. An agent who sees "claims to be [sam@acme.com](mailto:sam@acme.com)" can
act on that with judgement. It just never adds up to proof.