The identifiers at a glance
Synap organizes memory around five identifiers. Two describe your infrastructure (who you are and what you deployed); three describe who your agent is serving and drive how memory is scoped.B2C vs B2B: which scopes apply to you
How many of these scopes you actually use depends on your Instance’s tenancy shape. This is set once per Instance by the User Relationship setting (in the Dashboard, under Instance Settings), and it decides whethercustomer_id is part of your scoping at all.
- B2C (personal app): one tier of users, with no organization above them. You identify each user by
user_idonly, and you never passcustomer_id(the customer scope is auto-resolved server-side). Memories live at the user scope, with client and world above them. This is the right model when your users are individuals: a companion app, a personal assistant, or your first hobby agent. - 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. This is what activates the customer scope: facts tagged at customer scope are shared across that tenant’s users, while user-scoped memories stay private to the individual.
customer_id. If it is a B2B relationship, include customer_id on every call. The default for a brand-new personal agent is B2C (user_id only).Clients and instances
Clients and Instances are Synap’s infrastructure layer: they describe who you are and what you deployed, not who your agent serves. Memory isolation itself happens along the Customer/User scope chain inside an Instance.What is a Client?
A Client is the top-level organizational entity in Synap. It represents your company, team, or application. When you sign up for Synap and create an account, you are creating a Client. Every Client has a unique identifier in the formatcli_<hex16> (for example, cli_a3f8b1c2d4e5f678). This identifier is immutable and used throughout the Synap API and SDK to scope operations to your organization. A Client carries human-readable metadata (name, website, description), arbitrary JSON context, and a status of active, inactive, or soft_deleted.
inactive or soft_deleted, all of its Instances are effectively suspended. No ingestion or retrieval operations will succeed until the Client is reactivated.What is an Instance?
An Instance is a deployed Synap memory agent. It is the unit of deployment: each Instance has its own isolated memory store, configuration, credentials, and scope hierarchy. You create Instances under a Client to represent different AI agents, environments (staging vs. production), or use cases. Every Instance has a unique identifier in the formatinst_<hex16> (for example, inst_7b2e9a1c3d4f5678). You never pass the instance_id directly on SDK calls: the Instance is resolved from the API key you authenticate with. Each API key (format synap_<random>) belongs to exactly one Instance, so the key both authenticates you and selects which Instance’s memory you are reading and writing.
What each Instance owns
Each Instance is a fully isolated environment. When you create an Instance, Synap provisions these resources exclusively for it:API Keys
synap_<random>) generated from the Dashboard. Each key authenticates the SDK and resolves to this Instance. The SHA-256 hash is stored; the raw key is shown once at generation time and can be individually revoked.Memory Architecture Config
Memory Store
Scoped Memory Boundaries
Customers and users
Customers and Users are your entities, not Synap’s. You provide thecustomer_id and user_id strings, and Synap uses them to organize and isolate memories. You do not need to register these identifiers in advance. Simply pass them during ingestion and retrieval.
What is a Customer?
A Customer represents a tenant or organization in your application. If you are building a B2B SaaS product, each of your client companies is a Customer. If you are building a consumer app, each household or account group could be a Customer. Customers are identified by acustomer_id string that you provide. This string is opaque to Synap: it can be a UUID, a slug, a database ID, or any identifier that is unique within your application. Synap uses it to create a memory boundary at the CUSTOMER scope level.
Examples of Customers: "acme_corp", "startup_xyz", "household_9a3f", "team_engineering".
On a B2C Instance there is no organization above the user, so you never pass customer_id: the customer scope is auto-resolved server-side. On a B2B Instance, customer_id is required on every call and is what shares facts across a tenant’s users.
What is a User?
A User represents an individual end-user of your application. Each person interacting with your AI agent is a User. Users are identified by auser_id string that you provide, following the same rules as customer_id: it is opaque to Synap and can be any unique identifier.
Users map to the USER scope, the narrowest and most private scope level. Memories stored at the User scope are visible only when that specific user_id is provided in a retrieval query.
Examples of Users: "user_alice_chen", "u_8b2f4a91", "github|12345", "employee_0042".
Conversations
A Conversation is a single chat or session for a user, identified by an optionalconversation_id you pass alongside user_id. It groups exchanges within the USER scope so the agent can distinguish “this session” from a user’s broader history. Conversation IDs are opaque strings; UUIDs are typical:
The scope chain
Synap uses a four-level hierarchical scope chain, ordered from narrowest (most private) to broadest (most shared):
User scope
The most granular scope. Memories stored at the user level are visible only when that specific user is the context for a retrieval query. Use this for personal information, individual preferences, and conversation-specific knowledge.Customer scope
Memories shared across all users within a customer or organization. Use this for company-wide knowledge, shared context, and organizational facts. In a B2B SaaS application, a “customer” is typically one of your client’s end-customer organizations. (On a B2C Instance this scope is auto-resolved and rarely used directly.)Client scope
Memories shared across all customers of your application. In the Synap hierarchy, you (the developer) are the Client. Client-scoped memories are visible to all users of all your customers. Use this for product knowledge, documentation, and announcements.World scope
Global knowledge shared across all Instances. This is rarely used directly by application developers. It exists primarily for Synap-managed global knowledge and cross-instance shared resources.How scoping works with retrieval
When your agent fetches context, Synap merges memories from all applicable scopes in the chain. The merge follows a strict priority order: narrower scopes take precedence over broader scopes.Retrieval flow
Identify applicable scopes
user_id and customer_id in the retrieval request, Synap determines which scopes to search. If both are provided, all four scope levels are searched. If only customer_id is provided, User scope is excluded.Search each scope
Merge and deduplicate
Rank and return
Scoping rules by parameters
What you pass during ingestion decides where a memory is stored; what you pass during retrieval decides which scopes are searched and in what priority order. Ingestion:customer_id is auto-resolved server-side, so passing user_id alone still lands at the USER scope. The “Neither” row (CLIENT scope) applies to both B2C and B2B.Priority resolution example
Consider a scenario where conflicting information exists at different scopes:Scoped ingestion and retrieval
Ingesting memories with scope
When you ingest content, the scope is determined by theuser_id and customer_id parameters:
Retrieving memories across scopes
When retrieving, Synap automatically includes all applicable scope levels:Scope hierarchy table
Common scoping patterns
Single-user personal assistant (B2C)
Single-user personal assistant (B2C)
user_id (omit customer_id, it is auto-resolved). Each user has completely isolated memory.Multi-tenant B2B SaaS
Multi-tenant B2B SaaS
user_id + customer_id. Ingest company documents with just customer_id. Use client scope for product documentation.Customer-first with optional personalization
Customer-first with optional personalization
user_id on specific ingestion calls.Never provide user_id without customer_id (on B2B)
Never provide user_id without customer_id (on B2B)
customer_id is auto-resolved.)