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

# Email history

> Review assistant email conversations alongside calls.

Assistant emails appear in **History** as soon as SendGrid delivers an inbound message. The complete exchange is grouped into one conversation row, like one call: customer → assistant → customer → assistant.

Each message stores a stable `thread_id` for the conversation and an `in_reply_to` ID for its immediate parent. Incoming replies are matched through the standard `Message-ID`, `In-Reply-To`, and `References` headers, with a compact thread token in the reply address as a fallback.

## History table

Use **Type → Email** to show email only. Direction describes how the conversation started: an inbound customer message stays inbound after the assistant replies, while a standalone outbound email is outbound. Search matches email addresses, subjects, and plain-text bodies; the assistant and status filters work across calls and email.

Email reply states use the shared History statuses:

| Email state           | History status |
| --------------------- | -------------- |
| Reply pending         | `in_progress`  |
| Reply sent            | `completed`    |
| Outbound email        | `completed`    |
| Reply failed          | `failed`       |
| No assistant assigned | `skipped`      |

Open an email row to read every inbound message and assistant reply chronologically, plus the thread ID, sender, recipient, subject, assistant, latest reply state/error, and attachment metadata. Attachment contents are not retained. Search also matches every grouped reply. The latest message time controls History ordering, so a new reply moves the conversation back to the top.

Assistant output is normalized before sending. If the model accidentally starts its body with `Subject:` or `Betreff:`, that line is removed because SendGrid already sends the subject as a separate email header.

## API and MCP

* REST: `GET /api/v1/history` and `GET /api/v1/history/emails/{id}` (`calls:read`)
* MCP: `list_history` and `get_email_history_item`

The list endpoint supports `type`, `direction`, `status`, `assistant_id`, `campaign_id`, `search`, `from`, `to`, `limit`, and `offset`.

The email **channel itself** — sending/receiving domains, per-address assistant assignments, and the workspace default sender name and signature — is also fully manageable via API and MCP: `GET`/`POST /api/v1/email/domains`, `GET`/`DELETE /api/v1/email/domains/{id}`, `POST /api/v1/email/domains/{id}/verify`, `GET`/`POST /api/v1/email/addresses`, `PATCH`/`DELETE /api/v1/email/addresses/{id}`, and `GET`/`PUT /api/v1/email/settings` (`assistants:read`/`assistants:write`). MCP tools: `list_email_domains`, `connect_email_domain`, `get_email_domain`, `verify_email_domain`, `delete_email_domain`, `list_email_addresses`, `create_email_address`, `update_email_address`, `delete_email_address`, `get_email_settings`, `update_email_settings`.