Security
Built with production security patterns from day one
Multi-tenant isolation, role-based access, and encrypted credentials are not add-ons — they are the foundation. Here is how we protect your data.
Tenant A
Tenant B
Your data is isolated at the database level
- Every workspace's data is enforced as separate by the database itself — not just application code
- Even if a software bug bypasses a query filter, the database independently blocks cross-workspace access
- Unique identifiers like contact IDs and template slugs are scoped per workspace — no collisions, no leakage
- Application queries add a second layer of workspace filtering for defense-in-depth
This is defense-in-depth: two independent layers of isolation — application and database — each capable of preventing cross-tenant access on its own.
Six roles, least-privilege by default
Synapse manages its own authorization. Your identity provider handles login — Synapse controls what each user can do inside the platform.
| Role | Access Level |
|---|---|
| Owner | All permissions including billing, workspace deletion, and ownership transfer. One owner per workspace, enforced at the database level. |
| Admin | All CRM permissions plus user management. Cannot access billing. |
| Developer | Flows, templates, segments, contacts, email logs, and developer tools. |
| Marketing | Flows, templates, segments, and analytics. The day-to-day operator role. |
| Operations | Read-only contacts, email logs, and analytics. For support and ops teams. |
| Viewer | Analytics read-only. For stakeholders who need visibility without edit access. |
The single-owner constraint is enforced at the database level — no application bug can create a second owner in your workspace.
API keys do exactly what they should — nothing more
Every API key has a scope that limits its access. Create keys in the dashboard and assign one of four scopes.
| Scope | Access |
|---|---|
| data | Event ingestion and contact management |
| reporting | Read-only analytics, email logs, and reports |
| management | Configure flows, templates, and segments |
| full | All of the above |
Key security
- Bcrypt-hashed at rest: Keys are cryptographically hashed with bcrypt before storage. Synapse never stores plaintext after creation.
- Shown once: The full key is returned only at creation time. Copy it immediately — it cannot be retrieved again.
- Instant revocation: Deactivate any key immediately. Active keys stop working within seconds.
- Expiration support: Set an expiration date when creating keys. Expired keys are automatically rejected.
- Usage tracking: Every key logs its last-used timestamp and IP address for audit visibility.
- Environment separation: Create separate keys for test and live environments. Test keys process events without sending real emails.
Two auth layers for two use cases
Dashboard auth
- Secure token-based authentication for dashboard users
- Tokens are cryptographically signed and verified on every request
- JWKS keys cached locally with 6-hour TTL — no per-request network call to the identity provider
- If the identity provider experiences downtime, existing sessions continue working
- Token claims are mapped to Synapse's own RBAC system
API auth
- X-WORKSPACE-ID + X-API-KEY headers on every request
- Alternative: HTTP Basic Auth
- Key scope checked before every operation
- No dependency on the identity provider — works independently
Network and transport security
Cloudflare protection
- Web Application Firewall (WAF) with managed rulesets
- DDoS protection on all proxied domains
- Security headers injected at the edge (X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy)
TLS everywhere
- TLS 1.2 minimum enforced, TLS 1.3 supported
- Full (strict) SSL mode — end-to-end encryption
- HTTP automatically redirected to HTTPS
Per-tenant rate limiting
Every API request is rate-limited per workspace using a Redis sliding-window algorithm. Rate limits scale with your plan tier.
- Application-level rate limiting: Sliding-window counters per workspace. Limits adjust per plan tier.
- Infrastructure-level rate limiting: Nginx rate limiting at 100 requests/second per IP for API endpoints, 20 requests/second for auth endpoints.
- Standard rate limit headers: X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset on every response. Retry-After header on 429 responses.
- Graceful degradation: If Redis becomes unavailable, rate limiting degrades open (allows all requests) rather than blocking legitimate traffic.
What we encrypt and how
- API keys: Bcrypt-hashed at rest. Only the prefix (12 characters) and hash are stored. Plaintext shown once at creation, never stored.
- Database at rest: AES-256 encryption via GCP managed encryption keys. All storage and backups are encrypted.
- Data in transit: TLS 1.2+ on all connections. Full (strict) SSL mode through Cloudflare.
- Webhook secrets: Used for signature verification on every incoming webhook. Tampered payloads are rejected.
- Production secrets: Stored in GCP Secret Manager with version-based rotation support. Never in application code or environment files.
- Record identifiers: All primary keys use UUIDs — sequential IDs never expose record counts or creation order.
Webhook signature verification
All incoming webhooks from external services are cryptographically verified before processing. Unsigned or tampered payloads are rejected in production.
Resend (email delivery)
Svix signature verification (svix-id, svix-timestamp, svix-signature headers)
Lemon Squeezy (billing)
HMAC-SHA256 verification via x-signature header
pyrx.payment (payment processing)
HMAC with hmac.compare_digest and rotation support (comma-separated secrets)
Every action is logged
Synapse maintains a full audit trail that records changes across the platform. Each audit log entry includes workspace, user, action type, resource, IP address, and a details payload. Structured logging includes workspace, request, and user context in every log entry for end-to-end traceability.
Email delivery creates a log record for every send attempt — successful or failed. Failed sends capture the reason, error classification, and retry count.
Honest about where we are
Synapse is in early access. Here is what our security posture does not yet include:
| Gap | Status | Plan |
|---|---|---|
| SOC 2 Type I/II certification | Not started | On the roadmap as customer base grows |
| SLA with uptime commitment | Not published | No public uptime guarantee yet |
| Bug bounty program | Not available | Will consider as the platform matures |
| GDPR data processing agreement | Not published | Template DPA in development |
| Multi-region deployment | Single region (Singapore) | Additional regions planned based on customer demand |
| Customer-managed encryption keys | Not available | Using GCP-managed AES-256 encryption |
We believe in earning trust through transparency, not through claims we cannot back. If your security requirements include any of the items above, contact us to discuss our timeline and whether Synapse is the right fit today.
Where your data lives
- Cloud provider: Google Cloud Platform (Singapore region)
- Database: PostgreSQL with row-level security and encrypted connections
- Backups: Daily automated backups with 7-day retention
- Caching: Redis for rate limiting, idempotency, and circuit breaker state
- Email delivery: Resend — Synapse is the intelligence layer above the delivery provider
- Identity: Third-party identity provider for dashboard authentication
- Billing: Third-party Merchant of Record — we never touch credit card data
- DDoS protection: Cloudflare WAF and DDoS mitigation on all domains
Questions about our security posture?
We are happy to walk through our architecture, discuss specific requirements, or share additional technical detail.