Where to start, depending on what you’re trying to do
- “I just want to try Synap without installing anything”: open the live playground and exercise the SDK from your browser.
- “I want to see Synap working in 10 minutes”: you’re on the right page. Stay here.
- “I want to wire Synap into a real FastAPI / Flask / Next.js / Django app”: head to Setup & Integration after you finish this page.
- “I want a complete end-to-end tutorial with an LLM, conversation routing, and graceful degradation”: go to First Integration. That tutorial assumes you’ve finished this Quickstart.
- “I use a framework (LangChain, LangGraph, Vercel AI SDK, CrewAI, LiveKit, Claude Agent SDK, Pipecat…)”: you won’t call most of these APIs directly. Skim this page for the mental model, then jump to your integration.
The five identifiers, at a glance
Everything in Synap is scoped by these. You’ll see them throughout this page:| Identifier | What it is |
|---|---|
| Instance | An agent you integrate with Maximem Synap (resolved from your API key, not passed per call). |
User (user_id) | The end user of your agent (B2B or B2C). Passed on most calls. |
Customer (customer_id) | (B2B only) one of your customer organizations. On B2C it is auto-resolved, so you omit it. |
Conversation (conversation_id) | One chat thread. Must be a valid UUID. |
| Client | Your own organization account, which contains your instances. |
TL;DR: Hello World
If you already have an API key, this is everything you need to ingest one memory and read it back. This default is for a B2C app: one user (you), identified byuser_id alone:
hello_synap.py
Building a multi-tenant B2B app? add customer_id
Building a multi-tenant B2B app? add customer_id
On a B2B instance, every user lives under a tenant, so each call also carries a See B2C vs B2B below to tell which kind of instance you have.
customer_id. Pass it on both ingestion and retrieval:B2C vs B2B: which one are you?
Synap supports two tenancy shapes, and your Instance is set to exactly one of them via the User Relationship setting in the Dashboard (Instance Settings). This single choice decides whethercustomer_id is required on every call.
- B2C (personal app): one tier of users, no tenant above them. You identify each user by
user_idonly.customer_idis auto-resolved server-side, so you never pass it. This is the right model when your agent’s users are individuals (a companion app, a personal assistant, your first hobby agent, one user: you). - B2B (multi-tenant): your customers are organizations, each containing many users. Every user is scoped under a
customer_id, so you pass bothuser_idandcustomer_idon every call. Memories tagged at customer scope are shared across that tenant’s users; user-scoped memories stay private to the user.
customer_id (the examples in the main flow below). If it’s a B2B relationship, add customer_id to every call (the B2B accordions). When in doubt, the default for a brand-new personal agent is B2C.
This page’s main walkthrough uses the B2C shape. Each step includes a B2B accordion showing the extra customer_id.
Prerequisites
- Python 3.11 or later
- A Synap account (sign up at synap.maximem.ai)
piporpoetryfor package management
Set Up Your Client
A Client is your organization’s top-level account in Synap. Every instance belongs to a Client. You have two options:Create a new Client
- Log in to the Synap Dashboard
- Click Create Client, enter your organization name, and confirm
Skipping this step is not possible: every instance must belong to a Client. If you are unsure whether your organization already has one, check with your team before creating a new Client.
Create an Instance
An instance is an isolated memory environment for your agent. Each instance has its own storage, configuration, and scope hierarchy.
- In the Dashboard, navigate to Instances in the sidebar
- Click Create Instance
- Fill in the instance form:
- Name (required): A human-readable label, e.g.
"My First Agent" - Agent Type (optional): The kind of agent you’re building (e.g.
B2B Customer Support,B2C Companion,Workflow Agent). It seeds a sensible starting memory configuration for that use case. Skip it and Synap applies a default; you shape memory more precisely with the Use-Case Markdown file below, which you can update any time. - Description (optional): A short description of what this instance is for
- Use-Case Markdown (optional but recommended): Upload a
.mdfile describing your agent’s use case (see below)
- Name (required): A human-readable label, e.g.

Use-Case Markdown
The Use-Case Markdown file tells Synap what your agent does, who it serves, and what it should remember. Synap uses it to generate an optimized Memory Architecture Configuration (MACA) for your instance, so the more detail you provide, the better your memory extraction and retrieval will be from day one.Click Download Template in the Create Instance form, fill in at least the three required sections (Agent Objective, Target Users, Task Examples), and upload the file (.md, .markdown, or .txt, max 512 KB) before clicking Create.For the full template and section-by-section guidance, see Writing a Use-Case Markdown File.Generate an API Key
- In the Dashboard, go to your newly created instance
- Open the API Keys section on the instance detail page
- Click Generate API Key
- Give it a label (e.g., “development”) and click Generate
- Copy the key immediately: it starts with
synap_
Install the SDK
Now that you have a key, install the Synap SDK from PyPI:Verify the installation:
Streaming is enabled by default: no extra install needed.
Initialize the SDK
Set your API key as an environment variable:Create a new Python file:That’s it. The SDK reads You should see
main.py
SYNAP_API_KEY from your environment automatically.Run the script:Synap SDK initialized successfully!On Windows,
python is sometimes intercepted by the Microsoft Store app execution alias and fails with "Python was not found". Use py (the Windows Python launcher) instead: it ships with every official Python installer. The same applies to pip: py -m pip install maximem-synap always works regardless of PATH configuration.Ingest Your First Memory
Now let’s send a conversation to Synap. The ingestion pipeline will automatically extract structured knowledge: facts, preferences, entities, and more.
The SDK returns immediately with an ingestion ID. The pipeline processes the content asynchronously, extracting:
Building a multi-tenant B2B app? add customer_id
Building a multi-tenant B2B app? add customer_id
On a B2B instance, add
customer_id to scope this user under a tenant:- Fact: User is located in San Francisco
- Preference: User loves warm weather
- Temporal event: User is planning a trip to Japan next month
- Entities: San Francisco, Japan (resolved and linked in the knowledge graph)
Ingestion is asynchronous by design. The
memories.create() call returns as soon as the content is accepted by Synap Cloud. Processing typically completes within a few seconds, but complex documents may take longer.Retrieve Context
Once memories are ingested and processed, you can retrieve relevant context. Synap searches across both vector and graph storage, ranks results by relevance, and respects scope boundaries.The ingestion above used
Example output:You can now inject this context into your LLM’s system prompt or conversation history to create a personalized, context-aware experience.
Match the retrieval interface to the scope you ingested at. Synap has three scope-specific retrieval methods, and a memory is only returned through the one that matches how it was tagged:
A memory tagged with multiple identifiers is retrievable through any matching interface. A conversation is registered only by
| If you ingested with… | Retrieve via… |
|---|---|
user_id=... (B2C) or user_id=... + customer_id=... (B2B) | sdk.user.context.fetch(user_id=...) |
customer_id=... (no user) | sdk.customer.context.fetch(customer_id=...) |
A conversation registered via record_message(...) | sdk.conversation.context.fetch(conversation_id=...) |
record_message(...); passing a conversation_id in memories.create(metadata=...) does not register it, because metadata is stored alongside the memory but is not indexed for scope resolution. Calling conversation.context.fetch with a brand-new, unregistered conversation_id returns empty results by design: there is no conversation row to anchor scope resolution. See Context Fetch for the full reference.B2C vs B2B scoping. On B2C instances there is no customer dimension, so
customer_id is auto-resolved from user_id and you omit it; that’s the example below. On B2B instances, memory is scoped to a (user_id, customer_id) pair, so when you fetch at user scope you must pass both identifiers; omitting customer_id raises an error.user_id="user_123", so retrieve at user scope (B2C, customer_id is auto-resolved):Building a multi-tenant B2B app? add customer_id
Building a multi-tenant B2B app? add customer_id
On a B2B instance you ingested with
customer_id="acme_corp", so pass both identifiers at user scope:Clean Up
Always shut down the SDK cleanly to flush any pending operations and release resources:The complete script looks like this:
main.py
Close the loop: retrieve → generate → ingest
A real agent doesn’t ingest in isolation. It fetches relevant context, calls the LLM with that context, and ingests the resulting turn back into memory. That is the atomic unit of using Synap. Here’s the minimum-viable version with OpenAI (B2C,
For a fully-worked FastAPI + OpenAI app (including error handling, graceful degradation, and conversation routing), continue to the First Integration guide.
user_id only):conversation_id must be a valid UUID: the server rejects non-UUID strings. Generate one per chat thread with uuid.uuid4() and reuse it across that thread’s turns.The
metadata={"conversation_id": ...} on memories.create is for your own bookkeeping: it travels with the memory but is not indexed, so it does not register the conversation or affect scope resolution. The conversation is registered solely by record_message(...) in step 1.Building a multi-tenant B2B app? add customer_id
Building a multi-tenant B2B app? add customer_id
On a B2B instance, thread
customer_id through every call alongside user_id:What’s next?
You’ve successfully ingested your first memory and retrieved context. Here’s where to go from here:Core Concepts
Understand the full Synap architecture: scopes, memory types, entity resolution, and the ingestion pipeline.
SDK Configuration
Configure the SDK for your production environment: timeouts, retries, logging, and credential management.
Memory Architecture
Learn how to configure what gets extracted, how it’s stored, and how retrieval ranking works.
Production Checklist
Security, performance, monitoring, and reliability best practices before going live.