Skip to main content

Overview

The Synap SDK is configured via the SDKConfig object, which controls storage, credentials, caching, timeouts, retries, and logging. Sensible defaults are provided for all fields, so you only need to override what matters for your environment.

SDKConfig Reference

Field Reference

At a glance, SDKConfig accepts:
  • storage_path: directory for the local SQLite cache and transient state. Defaults to an SDK-managed directory. The API key is never written here; it is read from SYNAP_API_KEY (or the api_key= constructor argument) on each start. See Storage Path.
  • cache_backend: "sqlite" (default) for on-disk caching, or None to disable it. See Cache Backend.
  • session_timeout_minutes: how long a session stays active before re-authentication. Default 30, valid range 5 to 1440. See Session Timeout.
  • timeouts: a TimeoutConfig for per-operation network timeouts.
  • retry_policy: a RetryPolicy for transient-error retries, or None to disable retries.
  • log_level: logging verbosity, one of "DEBUG", "INFO", "WARNING" (default), "ERROR". See Log Level.

Full parameter reference →

The complete field list, types, accepted ranges, and the configure() rules (including the logger override).

TimeoutConfig

Controls how long the SDK waits for individual network operations.
connect
float
default:"5.0"
Maximum time in seconds to establish a TCP connection to Synap Cloud. Increase this if your network has high latency or unreliable DNS resolution.
read
float
default:"30.0"
Maximum time in seconds to wait for a complete response after sending a request. This should be higher than your expected query latency. For compaction of very large conversations, you may need to increase this.
write
float
default:"10.0"
Maximum time in seconds to upload request data. Relevant for large batch ingestion payloads. Increase if you are sending very large documents.
stream_idle
float
default:"60.0"
Maximum idle time in seconds for the SDK’s real-time event stream (used by sdk.instance.listen()). If no data is received within this window, the stream is considered stale and reconnected. Increase for low-traffic instances where events are infrequent.

RetryPolicy

Controls automatic retry behavior for transient errors.
max_attempts
int
default:"3"
The total number of attempts including the initial request. Setting this to 1 means no retries (only the initial attempt). Setting to 5 means up to 4 retries after the initial failure.
backoff_base
float
default:"1.0"
The base delay in seconds for exponential backoff. The delay for attempt N is backoff_base * 2^(N-2), capped at backoff_max. A higher base means longer waits between retries, which is gentler on rate-limited endpoints.
backoff_max
float
default:"10.0"
The maximum delay in seconds between retry attempts. Prevents exponential backoff from growing unbounded for high max_attempts values.
backoff_jitter
bool
default:"True"
When enabled, adds a random component to the backoff delay. This prevents the “thundering herd” problem where multiple SDK instances retry at the exact same time after a shared failure. Strongly recommended for production deployments.
retryable_errors
List[str]
The list of error type names that should be automatically retried. Only errors in this list trigger the retry policy. All other errors are raised immediately.For RateLimitError, the SDK uses the server-provided retry_after_seconds value instead of the exponential backoff calculation.

Storage Path

The storage_path directory holds the local SQLite cache and transient state. The SDK sets restrictive filesystem permissions on this directory on creation. The API key is never stored here; it comes from SYNAP_API_KEY or the api_key= constructor argument.

When to Override

Credentials

The SDK reads the API key on every start. There are exactly two sources: The SDK uses your API key for every call. The instance ID is resolved automatically from the API key; you do not need to set it manually.

Cache Backend

The SQLite cache stores recent retrieval results locally, enabling sub-millisecond cache hits for repeated queries. The cache respects TTL values from the server (ttl_seconds in response metadata) and evicts stale entries automatically. Benefits:
  • Sub-millisecond cache hits for repeated context fetches
  • Persists across SDK restarts (within TTL)
  • Automatic size management and TTL-based eviction
  • Zero configuration (SQLite is bundled with Python)

Disabled

Disables local caching entirely. Every conversation.context.fetch() call goes to Synap Cloud. Use this when:
  • You need guaranteed freshness on every call
  • You are running in a read-only filesystem (and cannot use a RAM-backed path)
  • You are debugging cache-related issues

Session Timeout

The session timeout controls how long the SDK’s authenticated session remains valid before re-authentication is required. The valid range is 5 to 1440 minutes (24 hours).

Log Level

The SDK uses Python’s standard logging module. The log level controls verbosity of the synap logger.
The DEBUG level may log sensitive information including request payloads. Do not use DEBUG in production environments where logs may be exposed to unauthorized parties.

Using configure()

The configure() method allows you to update individual configuration fields after constructing the SDK but before calling initialize().
Calling configure() after initialize() raises InvalidInputError('Cannot reconfigure after initialization').

Environment Variables

Only SYNAP_API_KEY is read from the environment. All other SDK settings must be set in code via SDKConfig; pass it to the constructor (or configure()) before initialize().

Common Configurations

Verbose logging, short timeouts, and aggressive retries for fast feedback during development.
Conservative timeouts, standard retries with jitter, minimal logging, and persistent storage.
Isolated storage, disabled caching for deterministic tests, no retries for immediate failure feedback.
Optimized for batch ingestion workloads with generous timeouts, higher retry limits, and long sessions.

Full Configuration Example

Putting it all together with explicit values for every field:

Next Steps

Initializing the SDK

Learn the full initialization lifecycle with configuration.

API Error Reference

Understand how retry policies interact with the error hierarchy.

Production Checklist

Review configuration best practices before going live.

Ingesting Memories

Start ingesting data with your configured SDK.