Docs Memory API

What the Memory API does

The Memory API turns time-stamped records from your systems into memories an agent can recall: current facts, their history, and the sources behind them, filtered by who is asking.

#The short version

You send: Records: text with a stable sourceId, the time it happened, who wrote it and who may see it.
Auld keeps: Memories extracted from records, reconciled so one fact has one current version and a dated history.
You ask: A recall: a query, a viewer identity, optionally a point in time and a token budget.
You get: Ranked memories with state, validity times and source excerpts, sized to fit your prompt.

#Surfaces

Surface	Use it for	Docs
REST API	Backends, pipelines, framework tools	API reference
MCP servers	Letting an MCP client call memory tools directly	MCP overview
Plugins	Coding agents and IDEs	Plugins
Webhook sources	Receiving events from other systems	Webhooks

#Request lifecycle

Send
POST /v1/records returns 202 with a jobId. Nothing is extracted yet.
Process
The record is split into candidate memories, matched against existing ones, and either added, merged or used to supersede.
Complete
GET /v1/jobs/{jobId} reports completed with counts of created and superseded memories.
Recall
POST /v1/recall ranks visible memories for the query and returns them with sources.

#Base URL and versioning

All paths are under /v1 on your project’s host. In these docs the host is written as $AULD_API_BASE. Additive changes (new fields, new endpoints) can ship at any time; clients should ignore unknown fields. Breaking changes are announced in the changelog before release.

Environment

export AULD_API_BASE="https://YOUR-AULD-HOST"   # your project's endpoint
export AULD_API_KEY="sk_live_…"                 # a project secret key

#Where to go next

Quickstart — four calls, end to end
Concepts — projects, records, memories, identities, audiences
Setup — a production integration step by step