> ## 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.

# Cross-channel customer memory

> Carry consented customer context across voice, email, web, and connected messaging channels

Customer memory connects exact, verified identities to one Audience contact and maintains a compact conversation summary. A customer can therefore continue in another channel without repeating known preferences, agreements, or open items.

Operational channels are Voice, SMS, WhatsApp, Email, Telegram, Slack, Messenger, Microsoft Teams, Discord, Google Chat, and X. Web memory is reserved for a future server-verified signed-in user identity. Anonymous widget form fields, browser participant names, phone numbers, and email addresses are untrusted and never unlock or update memory.

## Identity safety

* Phone numbers and email addresses are normalized and hashed for memory lookup.
* Provider-issued user IDs are matched exactly within the workspace and channel.
* Display names and transcript content are never used to merge contacts.
* Conflicting identities enter a review queue; they are never merged automatically.
* WhatsApp uses the peer `from` / `wa_id`, never the business display number.
* Email links only after an aligned DKIM pass, or an SPF pass whose SMTP-envelope domain aligns with the visible From domain. The message body and an unauthenticated From header never link contacts or unlock memory.
* Anonymous browser calls and chats do not currently participate in cross-channel memory. The Web selector stays unavailable until the platform can receive a signed, server-verified contact identity.

## Configure the workspace

Open **Workspace Settings → Data → Memory** to enable memory, select allowed channels, require consent, and choose a rolling retention period. An assistant can narrow the workspace policy under **Assistant → Settings → Data & Privacy → Customer memory** by selecting read channels, write channels, categories, and a scope.

| Scope       | Behavior                                                |
| ----------- | ------------------------------------------------------- |
| `workspace` | One shared memory across all assistants                 |
| `assistant` | Memory isolated to this assistant                       |
| `both`      | Shared customer context plus assistant-specific context |

Every read, write, consent change, skip, and deletion is audited. **Audience → Memory** lets workspace admins grant or withdraw consent and erase all shared and assistant-scoped memories for a contact.

## API and MCP

* `GET/PATCH /v1/settings/memory` manages workspace policy, including `memory_channels`, `memory_consent_required`, and `memory_retention_days`.
* `GET /v1/contacts/memory` lists customer memories.
* `GET/PATCH/DELETE /v1/contacts/{id}/memory` reads, updates consent/summary, or erases a contact's memory. PATCH requires the current workspace-memory `expected_revision`; update consent separately from summary/preferences. A stale revision returns `409`.
* Assistant updates accept `memory_scope`, `memory_read_channels`, `memory_write_channels`, and `memory_categories`.

The equivalent MCP operations use the same services and public-payload filtering as the REST API.

<Note>
  Only retain customer context with a lawful basis. Explicitly denied consent always prevents memory reads and writes. Unknown consent also blocks when the workspace requires consent.
</Note>