Skip to main content

Overview

Before your application can ingest memories or retrieve context, you must initialize the Synap SDK. Initialization validates your API key, establishes a secure connection, and prepares local caching. The SDK follows a strict initialize, use, shutdown lifecycle.

Basic Initialization

The simplest way to get started requires only your SYNAP_API_KEY environment variable. Generate an API key from the Synap Dashboard and set it in your environment.
You must call await sdk.initialize() before invoking any SDK operations. Calling methods like sdk.memories.create() before initialization raises an AuthenticationError.

What initialize() Does

When you call initialize(), the SDK performs the following steps in order:
1

Resolve API Key

The SDK picks up the API key from the api_key= argument (if passed) or the SYNAP_API_KEY environment variable.
2

Connection Establishment

The SDK opens an authenticated connection to Synap and, if real-time streaming is enabled, an additional streaming channel.
3

Cache Initialization

If a cache_backend is configured (default: sqlite), the SDK sets up the local cache database at the storage path.

Initialization with Custom Configuration

Pass an SDKConfig object to customize SDK behavior at construction time.
See SDK Configuration for a complete reference of all configuration options. For the full initialize() signature and parameters, see the API Reference.

Singleton Pattern

By default, the SDK maintains a single instance per instance_id, where instance_id defaults to "" (empty string) and is resolved from the API key at initialization. If you construct a second MaximemSynapSDK without passing instance_id, both constructions key off the same default empty string, so you receive a reference to the existing instance rather than creating a new one.
This prevents accidental duplication of connections and caches in applications that construct the SDK from multiple modules.
Instances are a Dashboard-only concept and are not SDK-addressable. Do not pass instance_id to disambiguate constructions; it is resolved automatically from the API key.

Overriding the Singleton for Testing

In test environments, use _force_new=True to bypass the singleton cache and create a fresh SDK instance each time.
The _force_new parameter is intended for testing only. Using it in production can lead to multiple SDK instances competing for the same credential files and cache database.

Running multiple instances in one process

The supported model is one live SDK per process. The singleton, the credential store, and the local cache database are all process-wide, so two SDKs constructed in the same process with the default instance_id collapse into the same object: you cannot point one at staging and another at production this way. To run staging and production side by side, give each its own process (separate worker, container, or service), each with its own SYNAP_API_KEY. Constructing multiple live SDKs in a single process is not a supported configuration and can lead to the credential/cache contention described above.

Environment Variable Initialization

For CI/CD, containers, serverless, and production, just set the environment variable:
The SDK reads SYNAP_API_KEY automatically and resolves the instance ID from the server.

The configure() Method

If you need to adjust configuration after constructing the SDK but before calling initialize(), use the configure() method.
Calling configure() after initialize() raises InvalidInputError('Cannot reconfigure after initialization'). All configuration must be finalized before the SDK is initialized.

SDK Lifecycle

The SDK follows a strict three-phase lifecycle:
SDK lifecycle: initialize, use, shutdown

1. Initialize

Call await sdk.initialize() to validate the API key and establish connections.

2. Use

Invoke SDK operations: sdk.memories.*, sdk.conversation.context.*, sdk.cache.*, etc. All operations are async and must be awaited.

3. Shutdown

Call await sdk.shutdown() to gracefully tear down the SDK.
Always call shutdown() before your application exits to ensure pending telemetry is flushed and active streaming connections are closed cleanly. Failing to call shutdown() may result in lost telemetry data and lingering connections.

Initialize and Shut Down Cleanly

For cleaner lifecycle management, wrap your application logic in a try/finally so shutdown() always runs, even if an error is raised mid-flight.

Full Example with Error Handling

The following example demonstrates a production-ready initialization pattern with comprehensive error handling.
The API key is read fresh on every start. There is no one-time setup step: the same SYNAP_API_KEY works forever (until you revoke it in the Dashboard).

Next Steps

Ingesting Memories

Send conversations and documents into Synap’s memory system.

Retrieving Memories

Query contextual memories for your AI agent.

SDK Configuration

Explore all configuration options in detail.