Skip to main content
You’re building a B2B SaaS app. Each of your customers has their own users. You want:
  • Memories from one customer to never leak to another.
  • Memories at the customer level (shared org policies, product config) to be visible to every user in that customer.
  • Memories at the user level (personal preferences) to stay private to that user.
Synap’s scope chain (USER → CUSTOMER → CLIENT → WORLD) maps to this cleanly. Use one Synap Instance for all your customers; rely on customer_id + user_id to enforce isolation.
Key isolation guarantees:
  • sdk.user.context.fetch(user_id="alice", customer_id="acme") returns only memories tagged with that exact user_id + customer_id pair, plus broader CUSTOMER and CLIENT scoped memories visible to acme. It does NOT return user “alice” from a different customer.
  • sdk.customer.context.fetch(customer_id="acme") returns customer-shared memories without leaking any user-scoped data.
  • A bug where you forget customer_id on memories.create() won’t quietly leak. On a B2B Instance it raises InvalidInputError.
Picking IDs
  • Use stable, deterministic strings: your internal customer UUID, your internal user UUID.
  • Don’t put PII in the IDs (no emails, names). Synap treats them as opaque identifiers but they appear in audit logs and telemetry.
One Instance vs many Instances Use one Instance for all customers when:
  • Customers share the same memory architecture (same Use-Case Markdown).
  • You don’t need separate residency / encryption keys per customer.
Use one Instance per customer when:
  • A customer has contractual data residency or KMS-key isolation requirements.
  • A customer needs a meaningfully different MACA (e.g., different memory types prioritized).

Going further