Skip to main content
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. 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.
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.