supermemory/apps/docs/snippets/api-v5-completion.mdx
Aswin-Ram-K c6fd728981 docs(api): add V3/V4 to V5 migration guide
## What and why

Add an agent-oriented V3/V4 to V5 migration guide covering document
ingestion and updates, content management, search, profiles, memory
forgetting, namespaces, organization settings, typed filters, and
rollout verification. Shared snippets keep the comprehensive guide and
the focused topic pages consistent, following the existing
`/snippets/*.mdx` import convention used elsewhere in the docs.

```mermaid
flowchart LR
  Legacy[Legacy integration inventory] --> Mapping[Domain migration guidance]
  Mapping --> V5[V5 requests and response readers]
  V5 --> Verify[Side-by-side verification and rollout]
```

## Grounding

Every old-vs-new claim traces to code in this repository:

- `packages/validation/api.ts` - `SearchRequestSchema`,
  `Searchv4RequestSchema`, `ListMemoriesQuerySchema`,
  `MemoryUpdateSchema`, `BulkDeleteMemoriesSchema`,
  `ContainerTagListTypeSchema`, `SearchFiltersSchema`.
- `packages/validation/schemas.ts` - `MemoryEntrySchema`,
  `OrganizationSettingsSchema`, `MemoryRelationEnum`.
- `packages/tools/src/shared/memory-client.ts` and
  `packages/tools/src/shared/types.ts` - the `/v4/profile` request and
  `profile.static` / `profile.dynamic` / `profile.buckets` reader.
- `apps/mcp/src/server/client/index.ts` - live `/v3/container-tags/list`,
  `/v4/memories/list`, and `/v3/documents/file` call sites.

## Notable findings documented

- `SearchFiltersSchema` is `z.array(z.unknown())` behind a
  `// TODO: Improve filter schema` comment, so legacy conditions were
  never validated at the edge. The typed-filter page documents the
  mechanical conversion and calls out the numeric-string-to-JSON-number
  trap that a straight rename would miss.
- `OrganizationSettingsSchema` carries connector credentials that are
  absent from the public V5 `/organization` response; the page warns
  against reading them from `GET /v3/settings`.
- Operations with no V5 replacement are listed explicitly rather than
  given invented substitutes.

## Validation

- `docs.json` parses as JSON; all 11 new nav entries resolve to authored
  pages, and every pre-existing nav entry still resolves.
- All 12 snippet imports and every relative/absolute link across the 23
  new files resolve to real targets.
- Fences, braces, and JSX component tags balance across all new files;
  frontmatter parses as YAML.
- `git diff --check` passes.

## Impact

Documentation only. No runtime, schema, or SDK behavior changes.
2026-09-23 03:18:51 -05:00

29 lines
1.3 KiB
Text

## Agent migration prompt
```text
Move this repository off the legacy Supermemory V3/V4 API and onto V5. Begin by
taking inventory: list every call site still targeting a legacy route. Then work
through the per-domain guides linked from this page. Address exactly one
namespace in each request. Where a default differs between the two versions,
state it in the request rather than relying on whatever the server supplies.
Bring response readers up to date as well. Back the change with contract tests
that exercise old and new side by side. Leave application routes unprefixed, and
leave connector routes alone. When an operation has been dropped, name it as
dropped rather than manufacturing a stand-in.
```
## Operations without a direct replacement
- **Direct memory creation and version updates** (`POST /v4/memories`,
`PATCH /v4/memories`): ingest or replace a source document instead.
- **Organization bucket suggestion** (`POST /v3/settings/suggest-buckets`) and
**organization reset** (`POST /v3/settings/reset`): not part of the V5 public
surface.
- **Connector routes** that still use `/v3`: unchanged; do not rewrite them.
## Where to go next
- [Authentication](/authentication) — unchanged bearer keys
- [Search guide](/recall/search)
- [Memory operations](/recall/memory-operations)
- [API reference](/api-reference/overview) — legacy V3/V4 reference