MemorySyncMemorySync
Getting Started

Architecture at a Glance

This is the runtime shape of MemorySync from a caller's perspective: the request entry point, the route groups it exposes, and the work it does before the handler runs.

Mounted route groups

PrefixMounted surface
/memoryMemory routes — add, query, summarize, forget, compose, routed search, graph, clusters, decisions, intelligence, export, refresh, and purge.
/authSignup, login, refresh, logout, and MFA.
/org/*API keys, projects, billing, webhooks, OAuth apps, and analytics.
/api/v1Integrations, web crawler, lifecycle, explainability, and refusals.
/scim/v2SCIM protocol routes.
/sso/* and /oauth/*SAML, OIDC, and OAuth browser flows.

What runs before every request reaches a handler

  • Authentication resolves the caller — either a JWT user or an API key.
  • Project scope is resolved on project-scoped routes from the X-Project-ID header or a project-locked API key.
  • Quota checks run before /memory/add and /memory/query.
  • Service-auth memory calls must identify the end user with X-End-User-ID.

Request path for <code>/memory/add</code>

  1. Authentication and project scope must resolve successfully.
  2. Add-quota enforcement runs. When the org is over quota, the route silently returns {"status":"ok"} without storing anything.
  3. The route resolves the effective end user, overwrites client-supplied user, environment, and project values with trusted context, and runs the memory through the extraction pipeline.
  4. If a record was stored, the handler emits the memory-created webhook and returns the first stored MemoryResponse.