Skip to main content

Endpoints

GET

Retrieve memories

POST

Create memory

PATCH

Update memory

DELETE

Delete memory

POST Batch

Create up to 25

Access and availability

Memory endpoints require a Developer API key with the corresponding scope: memories:read for reads and memories:write for writes. Creating a key is self-service in Developer → API Keys, and creation records the matching key grant when the key includes a memory scope. Default memory reads also have a separate, server-owned account readiness gate. A valid, correctly scoped key can therefore receive 403 while that account is not yet provisioned for Developer Memory API access. Do not recreate the key in that case; retry after the account is enabled or contact Omi support if it remains unavailable.
code is the stable programmatic signal. reason provides a diagnostic for the current server-side gate and must not be treated as a key or scope error.

Get Memories

GET /v1/dev/user/memories

Retrieve your memories with optional filtering

Query Parameters

Response Example

Create Memory

POST /v1/dev/user/memories

Create a new memory

Request Body

Duplicates and retries

A memory is identified by its text. Sending text the user already has returns that memory unchanged, with the same id, so a create is safe to retry without any extra header.Matching ignores leading and trailing whitespace and is case-sensitive. To change a memory you already created, use Update Memory with its id.

Response Example

Create Memories (Batch)

POST /v1/dev/user/memories/batch

Create multiple memories in a single request (max 25)

Request Body

Each memory object accepts the same fields as the single create endpoint.Items follow the same duplicate rule: text the user already has returns the existing memory at that position, so retrying a batch never stores anything twice. created_count is the number of memories returned, including existing ones.

Response Example

Update Memory

PATCH /v1/dev/user/memories/{memory_id}

Update a memory’s content or visibility

Path Parameters

Request Body

At least one field must be provided.

Response Example

Delete Memory

DELETE /v1/dev/user/memories/{memory_id}

Delete a memory permanently

Path Parameters

Response Example

This action is permanent. Deleted memories cannot be recovered.

What Are Memories?

Memories are timeless facts about the user. They cover preferences, relationships, personal details, and notable insights. They are NOT for notes, tasks, or time-sensitive information.
  • Good memories: “User is vegetarian”, “User’s sister Sarah lives in Portland”, “User prefers async communication”
  • Bad memories: “Meeting on March 15th”, “Call dentist tomorrow” (these are action items or conversations)
For notes, meeting summaries, or imported text content, use the Conversations API instead. It automatically extracts memories and action items.

Use Case: Store User Preferences

Import known facts and preferences about the user:

Memory Categories Explained

system

Useful context for the AI: preferences, work details, relationships, logistical info. Example: “User prefers dark mode”

interesting

Shareable, notable facts: things the user would excitedly tell someone at dinner. Example: “User climbed Mount Kilimanjaro”

Pagination and search coverage

List responses remain arrays. limit is clamped to 1–1000. Read X-Omi-Effective-Limit, X-Omi-Has-More, and X-Omi-Next-Offset for continuation. X-Omi-List-Truncated: true signals that the read budget ran out. An empty truncated page cannot guarantee progress; narrow the category filter or reduce the page size. Unknown list parameters are ignored and counted in X-Omi-Ignored-Query-Params, except query, which returns 400; use the search route. GET /v1/dev/user/memories/search?query=budget&limit=10 returns {memories, effective_limit, search_coverage, message} using the same eligible memory search as MCP. Limit is 1–20. It requires memories:read, the persisted app/key memory grant, and account readiness. Empty indexed results do not prove absence: inspect the memory list for unindexed content. Eligibility and privacy rules apply to both paths; archive is excluded by default. The existing /v1/dev/user/memories/vector/search remains available and reports effective_limit (at most 20) plus coverage and an empty-result message. The compatibility list has a 5000-item offset + limit window. Requests beyond it return 413. A full page ending exactly at that boundary reports truncated coverage without a next offset; it cannot certify that the account ends there.