Skip to main content
Run through this checklist before every production deployment, not just the first one. Configuration changes, SDK upgrades, and new features each warrant a fresh review.

Authentication and Security

Credential management is the foundation of a secure Synap integration. A compromised API key gives an attacker full access to your instance’s memory store.
1

API key stored in a secrets manager

Never hardcode API keys in source code, environment files committed to version control, or Docker images. Use a proper secrets manager:
  • AWS: Secrets Manager or SSM Parameter Store
  • GCP: Secret Manager
  • Azure: Key Vault
  • Self-hosted: HashiCorp Vault
API key is stored in a secrets manager (not in code, .env files, or container images)
2

Webhook signature verification implemented

If you receive webhooks from Synap, always verify the signature before processing the payload. Unverified webhooks can be spoofed by attackers.
Webhook signature verification is implemented and tested
3

API key rotation schedule established

API keys should be rotated periodically. You can have multiple active keys per instance, so rotation is zero-downtime: generate a new key, roll it out, then revoke the old one.
  • Recommended rotation cadence: every 90 days for standard deployments, every 30 days for high-security environments
  • Document the rotation procedure in your team’s runbook
  • Automate rotation if possible (e.g., via a cron job or CI/CD step)
API key rotation schedule is established and documented

SDK Configuration

Proper SDK configuration ensures your integration performs well under production load and does not generate excessive logging or resource usage.
1

Log level set appropriately

In production, set log_level to "WARNING" or "ERROR". The "DEBUG" and "INFO" levels generate high-volume output that degrades performance and can expose sensitive information in log aggregators.
log_level is set to "WARNING" or "ERROR" (not "DEBUG" or "INFO")
2

Timeouts configured for your SLA

Default timeouts are suitable for most applications, but review them against your latency requirements:
Timeouts are reviewed and aligned with your application’s SLA requirements
3

Retry policy tuned

The default retry policy (3 attempts, exponential backoff with jitter) is appropriate for most use cases. Adjust if needed:
  • High-throughput systems: Reduce max_attempts to 2 to avoid retry storms
  • Critical operations: Increase max_attempts to 5 for reliability
  • Low-latency paths: Reduce backoff_max to limit total retry time
Retry policy is reviewed and tuned for your workload profile
4

Cache backend enabled

The SQLite cache backend significantly improves retrieval performance for repeated queries. Ensure it is enabled:
cache_backend is set to "sqlite" for production performance
5

Session timeout configured

The session_timeout_minutes setting controls how long an authenticated session lasts before requiring re-authentication. The default is appropriate for most cases, but adjust based on your security requirements:
  • Standard applications: 60-480 minutes (1-8 hours)
  • High-security environments: 5-30 minutes
  • Long-running batch processes: 720-1440 minutes (12-24 hours)
session_timeout_minutes is configured appropriately (range: 5-1440)

Memory Architecture

Synap generates each Instance’s memory configuration automatically from the use-case file you upload. Before going to production, make sure that file reflects the agent you are actually deploying.
1

Use-case file accurately describes the production agent

The use-case Markdown you uploaded at instance creation drives every memory decision: which categories are extracted, how scopes are partitioned, what retention behavior applies. Review it now and re-upload an updated version if the agent’s purpose, audience, or compliance requirements have shifted since you created the Instance.
Use-case file reflects the production agent’s behavior, audience, and compliance posture
2

Verify retrieval quality on representative queries

Before going live, run a handful of representative production queries against the Instance and confirm the returned memories are relevant and complete. Catch retrieval drift before users do.
Retrieval quality validated on at least 10 representative queries
3

Confirm the Instance is in the active state

Check the Dashboard to confirm your Instance has moved from provisioning to active and that its memory architecture has been generated and applied. Do not start production traffic on an Instance that is still provisioning.
Instance status is active and ready to accept traffic

Error Handling

Robust error handling ensures your application degrades gracefully when Synap encounters issues, rather than crashing or returning empty responses.
1

All SynapError subtypes caught appropriately

Handle transient and permanent errors differently:
Error handling distinguishes between transient and permanent errors
2

Transient errors logged with correlation_id

Every SynapError includes a correlation_id field. Always log it: this is the primary identifier Synap support uses to trace issues.
All error logs include the correlation_id from the Synap error
3

Graceful degradation implemented

Your application should continue functioning when Synap is unavailable, just without memory context. This is the single most important resilience pattern.
Application continues working (without memory) when Synap is unavailable
4

Rate limit handling with retry_after

When you receive a RateLimitError, respect the retry_after_seconds field before retrying:
Rate limit errors are handled with proper backoff using retry_after_seconds

Monitoring

Observability is critical for understanding how your Synap integration performs in production and catching issues before they impact users.
1

Dashboard analytics reviewed regularly

The Synap Dashboard provides real-time analytics for each instance:
  • API call volume and success rate
  • Memory counts by category and scope
  • Ingestion throughput and processing latency
  • Retrieval latency percentiles (P50, P95, P99)
Establish a regular review cadence (at least weekly).
Dashboard analytics overview showing API volume, memory counts, and latency
Dashboard analytics are reviewed on a regular schedule
2

Webhooks configured for critical events

Set up webhooks to receive notifications for important events:
  • ingestion.failed: ingestion pipeline errors
  • credential.expiring: credentials approaching expiration
  • config.applied: configuration changes
  • retention.cleanup: memory retention cleanup completed
See Dashboard Webhooks for setup instructions.
Webhooks are configured for critical operational events
3

P95 latency baseline established

Synap does not publish per-operation latency SLOs; real numbers depend on your MACA configuration, payload sizes, retrieval mode, network path, and traffic shape. Measure your own staging baseline and set alert thresholds from that baseline.Recommended approach:
  1. Run a representative mix of memories.create(), context.fetch() (both fast and accurate), and memories.batch_create() against your staging Instance.
  2. Record P50 / P95 / P99 for each operation over a representative window (at least 1 hour of realistic traffic).
  3. Set production alert thresholds at a multiple of your staging P95 (e.g., 2-3× P95) so normal variance doesn’t page you.
  4. Re-baseline after any MACA change, SDK upgrade, or significant traffic-pattern shift.
P95 latency baselines are established from your own staging measurements and alert thresholds are derived from those baselines
4

Error rate alerts configured

Set up alerts in your monitoring system (Datadog, PagerDuty, CloudWatch, etc.) for:
  • Synap API error rate exceeding 1% over 5 minutes
  • Authentication failures (any occurrence)
  • Rate limit hits exceeding your expected threshold
  • Retrieval returning zero results when memories are expected
Error rate alerts are configured in your monitoring platform
5

Cost tracking enabled

If your Synap plan includes usage-based pricing, track your usage against budget:
  • API call volume (ingestion + retrieval)
  • Storage usage (vector + graph)
  • Bandwidth usage
The Dashboard provides usage breakdowns on the billing page.
Usage and cost tracking is enabled and reviewed regularly

Performance

Optimization ensures your integration meets latency requirements and minimizes unnecessary resource usage.
1

Using fast mode for latency-sensitive paths

Use mode="fast" for any operation in the critical path of user-facing requests. Reserve mode="accurate" for background tasks, research queries, or paths where the user is willing to wait.
Fast mode is used for all latency-sensitive code paths
2

Batch ingestion for bulk operations

When ingesting multiple documents, use batch_create() instead of multiple create() calls:
Batch ingestion is used for all bulk operations
3

Context compaction enabled for long conversations

For conversations that span many turns, use context compaction to keep the context within your LLM’s token budget:
Context compaction is configured for conversations that may exceed token budgets
4

Cache is enabled

Verify the cache backend is active and functioning:
cache.stats() is synchronous and returns a dict with enabled, client_id, base_path, total_entries, total_bytes, and per-backend stats under backends. If enabled is False or total_entries stays at 0 over time, your cache backend isn’t engaged; check SDKConfig.cache_backend.
Cache backend is enabled and accumulating entries

Operational Readiness

Beyond code and configuration, production readiness requires documented procedures and team alignment.
1

Team roles assigned appropriately

In the Synap Dashboard, assign roles based on the principle of least privilege:
Team members have appropriate roles (not everyone is Owner)
2

Credential rotation runbook documented

Document the step-by-step procedure for rotating API keys:
  1. Generate new key in Dashboard
  2. Update secrets manager with new key
  3. Deploy application with updated secret reference
  4. Verify new key is working (check Dashboard for API calls)
  5. Revoke old key after grace period (48 hours)
Credential rotation runbook is documented and accessible to the operations team
3

Support channel documented

Ensure your team knows how to get help:
Support channels are documented and the team knows how to report issues

Quick Summary

Use this condensed checklist for quick pre-deployment reviews:

Next Steps

Migrate from Competitors

Mapping your existing memory system (Mem0, Zep, Letta, SuperMemory) to Synap.

Monitoring and Analytics

Deep dive into Dashboard analytics and monitoring capabilities.

Error Handling

Complete reference for all Synap error types and handling patterns.

Webhooks

Configure webhooks for real-time event notifications.