Skip to main content
The Dashboard at synap.maximem.ai is the control plane for Synap: it’s where you create instances, configure how they remember, and provision the API keys your application uses. The data plane (ingesting memories and retrieving context) happens through the Synap SDK, not here. Most of the Dashboard is self-explanatory once you’re in it. This page orients you to the main areas; follow the in-app prompts for the rest.
Synap Dashboard home page showing instance overview, recent activity, and key metrics
Access is governed by three roles. Owners and Admins can create and edit instances, upload use-case files, and generate API keys. Members have read-only access. Owners additionally manage the team.

​
Managing instances

An instance is the fundamental deployment unit: an isolated memory agent with its own storage namespaces, memory configuration, scope hierarchy, and API keys. Each one is identified by an ID like inst_a1b2c3d4e5f67890. From the Instances page, Owners and Admins can Create Instance. Creation asks for a name, a user relationship (b2c, b2b, internal, or agent_to_agent), an optional agent type, and (recommended) a Use-Case Markdown file describing what the agent does. That file is what Synap uses to generate the instance’s memory architecture; download the in-form template to author it. For B2C agents, the customer and user collapse to the same entity. A new instance starts in initializing while Synap allocates storage and applies the initial configuration, then moves to active once the first SDK connection lands. Other lifecycle states (inactive, suspended, deleting) are shown on the instance, with the available actions for each. Everything for a single instance lives on its detail page: status and metrics, the memory configuration, analytics, and the Instance Settings where you rename it, edit metadata, re-upload the use-case file, and manage API keys.
API keys (prefixed synap_) are shown only once. Copy the key when you generate it and store it as your SYNAP_API_KEY. To rotate, generate a new key first, switch your environment over, then revoke the old one. Multiple keys can be active at once, so there’s no downtime.

​
Memory configuration

Every instance has a Memory Architecture Configuration (MACA) that Synap derives from its Use-Case Markdown. It shapes which memory categories are extracted, how retrieval ranks and combines results across the fast vector + graph layers, how memories are scoped (user, customer, client, or world), and how long they’re retained. The Dashboard surfaces MACA for inspection only. Open the Memory Configuration tab on the instance detail page to confirm what Synap configured and to see the history of past regenerations. It is not an authoring surface. To change behaviour, edit your Use-Case Markdown and re-upload it from Instance Settings → Use-Case. Synap regenerates the MACA from the new file; the previous versions are preserved (rollback is a Synap-side operation today, available via support). Regeneration affects only new requests. In-flight conversations finish under the settings they started with. For how MACA is derived and what each section governs, see Customized Memory Architectures and the Use-Case Markdown authoring guide.

​
Next steps

Customized Memory Architectures

How Synap derives an instance’s memory configuration from your use-case file.

Use-Case Markdown

Author the file Synap uses to configure and regenerate memory behaviour.

First Integration Guide

Connect your application to a dashboard-provisioned instance using the SDK.

Production Checklist

Review everything you need before going live.