mirror of
https://github.com/supermemoryai/supermemory.git
synced 2026-10-02 02:11:20 +00:00
## 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.
29 lines
1.3 KiB
Text
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
|