Member Memory Management API

Explains how signed-in members can manage their own persistent memories through the API.

Members can view and manage their own memories via /api/v1/me/memories/ (/api/me/memories/ behaves identically). Include X-Organization-Id in each request to specify the organization you are working with, including when calling with an API Key. The service retrieves data based on the caller's valid membership in that organization. For sign-in and common request conventions, see Quickstart.

Available Operations

Operation	Endpoint	Behavior
List	GET /api/v1/me/memories/	Lists the current member's active and expired memories. Filter using the status and kind query parameters.
Create	POST /api/v1/me/memories/	Creates a memory for the caller. If the same member already has an active memory with the same topic, updates that memory instead. Returns HTTP 201 for creation and HTTP 200 for updates.
Modify or reactivate	PATCH /api/v1/me/memories/{id}/	Modifies a visible memory or sets its status to active/expired.
Delete	DELETE /api/v1/me/memories/{id}/	Deletes a specified memory belonging to the caller.

For request fields (topic, summary, details, kind, status) and length limits, see the API documentation for each endpoint in the table above.

List and individual operations expose only active and expired memories. Memories awaiting confirmation or rejected memories do not appear in this member interface.

Handling Status in Integrations

If a member marks a memory as expired, integrations can still see it in the list and use PATCH to change its status back to active. Creating a memory without valid membership returns HTTP 404. Display memories for the organization specified in the request to avoid mixing data from different organizations on the same screen.