Skip to main content

​
Mental model

MemContext is the memory layer for your AI product. Your app sends durable context to MemContext, then retrieves relevant context before generation. Your application does not need to manage retrieval logic, duplicate memories, or memory updates manually.

​
Integration pattern

A typical integration follows four steps:
  1. Save durable user or project context via POST /api/memories
  2. Search before generation or decision-making via GET /api/memories/search
  3. Profile (optional) - fetch broad context in one call via GET /api/memories/profile
  4. Feedback - record retrieval quality via POST /api/memories/:id/feedback
For larger notes, POST /api/memories may return 202 Accepted. This means extraction has started and can be tracked with the returned jobId. For multi-user applications, always pass a stable end-user or tenant ID in scope. project remains a secondary grouping field inside that scope.

​
Example: Support bot

User: "I'm having trouble with my subscription"

Bot workflow:
1. search_memory({ query: "user subscription plan and billing" })
   → finds: "User is on the Pro plan, subscribed via Stripe"
   → finds: "User had a billing issue resolved on March 15"

2. Generate response with memory context injected into prompt

3. memory_feedback({ memoryId: "...", type: "helpful" })

​
Good fit use cases

Use caseMemory role
Coding assistantsStable preferences, project decisions, architecture context
Content generationBrand rules, evolving strategy, audience insights
Support botsCustomer history, past issues, plan details
CRM memoryRelationship context, interaction history
OnboardingUser progress, preferences learned during setup
PersonalizationStyle preferences, feature usage patterns

​
Ownership boundary

Keep your application logic outside MemContext. MemContext owns:
  • Saving and retrieving memory
  • Handling duplicates and updates
  • Memory history
  • Expiry and temporal filtering
  • MCP tool access
Your application owns:
  • Business-specific prompts and logic
  • UI and user experience
  • Workflow orchestration
  • Downstream actions and integrations

​
API integration example

const MEMCONTEXT_API = "https://api.memcontext.in";

async function searchMemory(query: string, scope: string, project?: string) {
  const params = new URLSearchParams({ query });
  params.set("scope", scope);
  if (project) params.set("project", project);

  const res = await fetch(`${MEMCONTEXT_API}/api/memories/search?${params}`, {
    headers: { "X-API-Key": process.env.MEMCONTEXT_API_KEY },
  });

  return res.json();
}

async function saveMemory(
  content: string,
  category: string,
  scope: string,
  project?: string,
) {
  const res = await fetch(`${MEMCONTEXT_API}/api/memories`, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "X-API-Key": process.env.MEMCONTEXT_API_KEY,
    },
    body: JSON.stringify({ content, category, scope, project }),
  });

  return res.json();
}
If you submit a long note or transcript, check the returned status:
  • saved, updated, extended, duplicate → final synchronous result
  • accepted → asynchronous extraction in progress

​
TypeScript SDK example

Install the SDK: 
npm install memcontext-sdk

import { MemContextClient } from "memcontext-sdk";

const client = new MemContextClient({
  apiKey: process.env.MEMCONTEXT_API_KEY!,
  scope: "user_123",
  project: "memcontext",
});

const profile = await client.profile();

await client.save({
  content: "User prefers TypeScript over JavaScript for type safety",
  category: "preference",
});

const results = await client.search({
  query: "What language does the user prefer?",
});

​
Tips

  • Search before saving - avoid duplicates by checking if the knowledge already exists
  • Use scope for hard per-user or per-tenant isolation
  • Use projects only to group memories inside that scope
  • Category matters - preference and fact go into profile static context; everything goes into dynamic
  • Do not save noise - only persist information with long-term value