Overview
The Synap SDK is configured via theSDKConfig 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
The directory where the SDK stores credentials, cache databases, and local state. The SDK creates this directory (and parents) if it does not exist.Override this when:
- Your application runs in a container with a specific writable volume
- Multiple SDK instances on the same machine need isolated storage
- You want to persist data in a location managed by your deployment tooling
Where the SDK reads authentication credentials from.
"file"— Read credentials from files instorage_path. After the initial bootstrap, credentials are persisted to disk and loaded on subsequent starts."env"— Read credentials from theSYNAP_API_KEYenvironment variable. Ideal for containers, serverless, and CI/CD.
The local cache implementation used to store recent retrieval results.
"sqlite"(recommended) — Uses a SQLite database instorage_pathfor local caching. Provides fast sub-millisecond cache hits, persistence across restarts, and automatic TTL-based eviction.None— Disables local caching entirely. Every retrieval call goes to Synap Cloud. Use this only when you need guaranteed fresh data on every call or are running in a read-only filesystem.
How long a session remains active before the SDK re-authenticates. Valid range: 5 to 1440 minutes (24 hours).Shorter timeouts improve security by limiting the window for credential misuse. Longer timeouts reduce re-authentication overhead for long-running processes.
Fine-grained timeout configuration for network operations. See TimeoutConfig below.
Configuration for automatic retry of transient errors. Set to
None to disable retries. See RetryPolicy below.The logging verbosity for the SDK’s internal logger. Uses Python’s standard logging levels:
"DEBUG"— Verbose logging including request/response details, cache hits/misses, retry attempts"INFO"— Initialization events, connection status, credential rotation"WARNING"— Deprecation notices, performance warnings, approaching rate limits"ERROR"— Only errors that affect operation
TimeoutConfig
Controls how long the SDK waits for individual network operations.Maximum time in seconds to establish a TCP connection to Synap Cloud. Increase this if your network has high latency or unreliable DNS resolution.
Maximum time in seconds to wait for a complete response after sending a request. This should be higher than your expected query latency. For
accurate mode retrieval (200-500ms typical), the default is generous. For compaction of very large conversations, you may need to increase this.Maximum time in seconds to upload request data. Relevant for large batch ingestion payloads. Increase if you are sending very large documents.
Maximum idle time in seconds for gRPC streaming connections (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.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.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.The maximum delay in seconds between retry attempts. Prevents exponential backoff from growing unbounded for high
max_attempts values.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.
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
Thestorage_path directory contains all SDK-managed local state: credentials, the SQLite cache database, and instance state. The SDK sets restrictive filesystem permissions on this directory automatically on creation.
The storage directory contains sensitive credential material. In containerized environments, mount this path to a persistent volume so credentials survive container restarts.
When to Override
| Scenario | Recommended storage_path |
|---|---|
| Standard deployment | None (use SDK default) |
| Docker container | /var/lib/synap/ mapped to a persistent volume |
| Serverless function | Use credentials_source="env" instead |
| Multiple instances on same host | /var/lib/synap/<instance_id>/ |
| Testing | /tmp/synap-test/ |
Credentials Source
File-Based (Default)
storage_path/credentials/. On subsequent SDK starts, they are loaded automatically without needing SYNAP_API_KEY again.
This is the recommended approach for persistent environments (VMs, containers with volumes, on-premise servers).
Environment-Based
| Variable | Description | Required |
|---|---|---|
SYNAP_INSTANCE_ID | Instance identifier | Yes (or pass to constructor) |
SYNAP_API_KEY | API key for authentication | Yes (or pass to constructor) |
Cache Backend
SQLite (Default, Recommended)
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
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
| Setting | Value | Use Case |
|---|---|---|
| Short session | 5-15 min | High-security environments, compliance requirements |
| Default | 30 min | General-purpose applications |
| Long session | 60-120 min | Long-running batch processes |
| Maximum | 1440 min (24h) | Background workers, data pipelines |
Log Level
The SDK uses Python’s standardlogging module. The log level controls verbosity of the synap logger.
| Level | What is Logged |
|---|---|
DEBUG | All internal operations: request/response bodies, cache lookups, retry decisions, credential rotation timing |
INFO | Initialization, connection events, credential rotation, compaction triggers |
WARNING | Deprecation notices, approaching rate limits, cache size warnings |
ERROR | Failed operations that could not be retried, authentication failures, data corruption |
Using configure()
The configure() method allows you to update individual configuration fields after constructing the SDK but before calling initialize().
Environment Variable Overrides
In addition to thecredentials_source="env" mode for credential management, several SDK settings can be overridden via environment variables. Environment variables take precedence over values in SDKConfig.
| Environment Variable | Overrides | Example |
|---|---|---|
SYNAP_STORAGE_PATH | storage_path | /var/lib/synap |
SYNAP_CACHE_BACKEND | cache_backend | sqlite or empty to disable |
SYNAP_LOG_LEVEL | log_level | DEBUG |
SYNAP_SESSION_TIMEOUT | session_timeout_minutes | 60 |
SYNAP_CONNECT_TIMEOUT | timeouts.connect | 10.0 |
SYNAP_READ_TIMEOUT | timeouts.read | 45.0 |
Common Configurations
Development
Development
Verbose logging, short timeouts, and aggressive retries for fast feedback during development.
Production
Production
Conservative timeouts, standard retries with jitter, minimal logging, and persistent storage.
Testing
Testing
Isolated storage, disabled caching for deterministic tests, no retries for immediate failure feedback.
High-Throughput
High-Throughput
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.