# past.dev developer documentation

> Add long-term memory to an agent or application. Use the Memory API from your software, or connect an MCP client to your past.dev account.
> Memory API: Send text through the API and query the stored memory from your code. You control the project. Your end users do not need past.dev accounts.
> MCP server: Connect Claude, Cursor, or another MCP client to your past.dev account. The client can read the information available to the signed-in user.
> Every page below is also available as Markdown by appending /llms.txt to its URL.

Full corpus in one file: https://past.dev/docs/llms-full.txt

To get an API key, sign up at https://sso.past.dev/sign-up, then create a project key in the console.

## past.dev MCP Server

- [What the past.dev MCP servers are](https://past.dev/docs/mcp/overview/llms.txt): past.dev operates two authenticated MCP servers: one for the people who administer an organization, and one for your product's end users.
- [Connect an MCP client](https://past.dev/docs/mcp/quickstart/llms.txt): Add the account server URL to your client, then sign in through your browser. No API key is required.
- [Available tools](https://past.dev/docs/mcp/tools/llms.txt): The account server carries 54 tools. Each one does what a console screen does, under your platform role and your reach on the project you name.
- [Use past.dev with your product's users](https://past.dev/docs/mcp/serving-your-own-users/llms.txt): Enable the end-user MCP server on a project. Your users reach that project's memory from their own assistant, signed in at your identity provider.
- [How it works](https://past.dev/docs/mcp/how-it-works/llms.txt): Both servers verify identity and permissions on every request. The client receives only the tools the caller holds at that moment.
- [Security](https://past.dev/docs/mcp/security/llms.txt): Short-lived OAuth tokens, permissions derived from server-side records on every request, and one tenant per caller.
- [Administrative controls](https://past.dev/docs/mcp/admin-controls/llms.txt): What an administrator controls on each server, and where that control lives in the console.
- [Privacy and compliance](https://past.dev/docs/mcp/privacy-compliance/llms.txt): The MCP servers use the same security and privacy controls as the rest of past.dev.
- [Limits and known behaviour](https://past.dev/docs/mcp/limits/llms.txt): Current behaviour and current product limitations.
- [Troubleshooting](https://past.dev/docs/mcp/troubleshooting/llms.txt): Check the address, the authentication method, the membership and the tool list.
- [Questions](https://past.dev/docs/mcp/faq/llms.txt): Common questions about access, administration, cost and setup.

## past.dev Memory API

- [What the Memory API does](https://past.dev/docs/memory-api/overview/llms.txt): Send timestamped text, wait for it to complete, then recall ranked memory with the data points behind it.
- [Quickstart](https://past.dev/docs/memory-api/quickstart/llms.txt): Get a key, send a fact, send the fact that supersedes it, wait for the send to complete, then recall as one identity.
- [Set up an integration, step by step](https://past.dev/docs/memory-api/setup/llms.txt): Every call in order, with the response value that lets you move to the next step.
- [Authentication](https://past.dev/docs/memory-api/authentication/llms.txt): Two kinds of bearer key open the API, and an agent token opens the memory routes for one person. Each route accepts the credentials it names.
- [Projects, data points, memories, audiences, identities and traits](https://past.dev/docs/memory-api/concepts/llms.txt): The five nouns of every call, the memories that recall returns, and every limit in one table.
- [How requests behave](https://past.dev/docs/memory-api/how-it-works/llms.txt): Acceptance, completion, replacement, recall and deletion, as your application observes them.
- [Scoping memory to customers, companies and deals](https://past.dev/docs/memory-api/access-control/llms.txt): Where a customer, a company or a deal lives, with the requests that put it there.
- [What to send and how to split it](https://past.dev/docs/memory-api/sending-data/llms.txt): The unit recall reads best, the size of one data point, the shape of its text, and the procedure for a historical load.
- [Receive events from another system](https://past.dev/docs/memory-api/webhooks/llms.txt): A webhook gives a project a URL. Another system posts events to the URL, and the filters decide which events become data points.
- [Endpoint reference](https://past.dev/docs/memory-api/api-reference/llms.txt): Thirty-four operations under /api/v1. Field names match the backend JSON contract.
- [When something looks wrong](https://past.dev/docs/memory-api/debugging/llms.txt): Four reads answer the questions an integration raises: where a send got to, what a memory was built from, what an import will cost, and what is left to spend.
- [Errors](https://past.dev/docs/memory-api/errors/llms.txt): Every refusal uses a JSON body with code, status, debugMessage, and optional data, except the per-minute limit, which answers with no body.

## Notes for assistants

- Field names, tool names and permission scopes are exact. Do not translate,
  reformat or guess them.
- The Memory API is unversioned and its paths may change.
- Anything not documented here does not exist yet. Known gaps are listed on
  each product's Roadmap or Limits page.
- To set up an integration, read Setup first: every call in order, with the response that
  gates the next step (https://past.dev/docs/memory-api/setup/llms.txt).
- One data point is one thing that happened, timed at its first message: one conversation
  for one day, one email, one record, one document. See Sending data before a historical load.
- `audience` on a data point decides who can read it. `identity` on a recall is the reader.
  `identity` on a data point is the optional author, never the scope. See Concepts.
- `metadata` is stored with the data point and never filters a recall. To read one scope only,
  recall as an identity whose only audience is that scope. See Access control.
- Poll `GET /api/v1/ingest/{ingestionId}` until `status` is `completed` for that send.
  `settled` describes every send in the project.