Security
Chimatic is the notification orchestration layer between your application and third-party providers. Because we manage notification infrastructure on behalf of your users — event data, notification content, and delivery metadata — security is not a feature we bolt on. It is the foundation of every architectural decision we make.
This page describes how we protect your notification data, what guarantees we provide, and how you can verify our practices.
Encryption
At Rest
All notification data — event data, notification content, and delivery metadata — is encrypted using AES-256-GCM before it is written to storage. We use authenticated encryption, which provides both confidentiality and integrity verification — any tampering with encrypted notification data is detected and rejected.
In Transit
All communications between your application, the Chimatic API, and third-party providers use TLS 1.3. We do not support older TLS versions. Certificate pinning is available for Enterprise customers using the self-hosted delivery engine.
Per-Tenant Key Isolation
Each workspace’s notification data is encrypted with a unique data encryption key (DEK). DEKs are themselves encrypted by a key encryption key (KEK) managed through hardware security modules. This architecture ensures that a compromise of one workspace’s DEK cannot expose notification data belonging to any other workspace.
Key rotation is automatic and transparent. When a KEK is rotated, all associated DEKs are re-encrypted without any service interruption or action required on your part.
Notification Data Management
Principle of Least Exposure
Chimatic is designed to minimize the surface area where notification data exists in plaintext:
- Never logged: Notification data is never written to application logs, error reports, crash dumps, or monitoring systems. Log redaction is enforced at the serialization layer, not through post-processing filters.
- Never displayed in raw form: The Chimatic dashboard shows only masked data prefixes for identification purposes. Full notification data values cannot be retrieved through the dashboard UI.
- Never used beyond their purpose: Notification data is used exclusively for authorized operations — notification delivery, event processing, and health checks to verify provider integrations are alive. We never use your notification data to call Provider APIs for any other reason.
Separation of Secrets
Provider credentials (the credentials that identify your application to a Provider) are stored separately from notification data (event data, notification content, and delivery metadata). These data classes use distinct storage backends with independent access controls, encryption keys, and audit trails. A compromise of the notification data store does not expose provider credentials, and vice versa.
Notification Data Lifecycle
When a notification channel is deactivated, Chimatic immediately removes the active notification data from storage. Notification data for deactivated channels is retained for a maximum of 30 days to allow for reactivation, after which it is permanently purged.
OAuth Security
PKCE (Proof Key for Code Exchange)
Chimatic enforces PKCE on all OAuth flows, even when the Provider does not require it. PKCE prevents authorization code interception attacks by binding the authorization request to the token exchange, ensuring that a stolen authorization code cannot be used by an attacker.
State Validation
Every OAuth flow includes a cryptographically random state parameter that is validated on callback. This prevents cross-site request forgery (CSRF) attacks where an attacker could trick a user into authorizing a connection to the attacker’s account.
Callback URL Allowlisting
Chimatic validates all OAuth callback URLs against a strict allowlist configured per Provider. Wildcard patterns are not permitted. This prevents open redirect attacks where an attacker could intercept authorization codes by manipulating the callback URL.
CSRF Protection
In addition to OAuth state validation, all Chimatic API endpoints that modify state are protected against CSRF through origin validation and token-based protections.
Enterprise Security
Control Plane / Data Plane Separation
Enterprise deployments support a split architecture where the control plane (notification channel configuration, provider integration catalog, delivery analytics) runs on Chimatic Cloud while the data plane (notification data storage, delivery, health checks) runs on your infrastructure. This means your notification data never leaves your network, while you still benefit from the managed Chimatic dashboard and configuration experience.
Customer-Managed KMS (BYOK)
Enterprise customers can bring their own KMS keys for notification data encryption. In this configuration, Chimatic cannot decrypt your notification data without access to your KMS — giving you full control over the encryption lifecycle, including the ability to revoke access and render all stored notification data unreadable.
Open-Source Delivery Engine
The Chimatic notification delivery engine — the component that stores, processes, and delivers notifications — is fully open source under the MIT License. Enterprise customers who deploy the self-hosted delivery engine can audit every line of code that handles their notification data. There is no proprietary black box between your notification data and your infrastructure.
Data Residency
Enterprise customers can choose where their notification data is stored to meet regulatory and compliance requirements. US and EU regions are available, with additional regions available on request.
Infrastructure
Deployment
Chimatic Cloud runs on Kubernetes with automated deployments, rolling updates, and instant rollback capabilities. Infrastructure is provisioned through infrastructure-as-code with full audit trails. All infrastructure changes require peer review and are logged immutably.
Network Isolation
Notification data storage is deployed in isolated network segments with no direct internet access. All access to the notification data store is mediated through the Chimatic API layer, which enforces authentication, authorization, and rate limiting. Database access requires mutual TLS authentication.
Secrets Management
Infrastructure secrets, including database credentials, provider API keys, and internal service tokens, are managed through a dedicated secrets manager with automatic rotation. Secrets are injected at runtime and never stored in source code, configuration files, or container images.
Monitoring and Incident Response
We maintain 24/7 automated monitoring for anomalous notification data access patterns, unusual delivery rates, and potential data exposure events. Our incident response process includes immediate data isolation capabilities and customer notification within 24 hours of confirmed incidents.
Penetration Testing
We conduct regular third-party penetration testing of the Chimatic API surface and infrastructure. Findings are remediated according to severity: critical and high findings are addressed within 48 hours; medium findings within 30 days.
Compliance
SOC 2 Type II
We are pursuing SOC 2 Type II certification targeting GA + 12 months. The audit will cover the Security, Availability, and Confidentiality trust service criteria. Once certified, we will make our SOC 2 report available to Enterprise customers under NDA upon request.
GDPR
Chimatic supports GDPR compliance through:
- Data residency: EU data residency option ensures notification data and event data remain within the European Union
- Right to erasure: Notification data and event data can be deleted through the API or dashboard at any time. Deletion is permanent and irreversible.
- Deletion API: A programmatic deletion API allows you to fulfill erasure requests from your end users by removing their specific notification channels and notification data without affecting other data
- Data processing agreement: Available for customers who require a DPA for their compliance documentation
Provider Compliance
When integrating with Providers that have their own compliance requirements (such as Google’s OAuth security policies or Slack’s app review process), Chimatic’s implementation follows Provider-recommended security practices, including mandatory PKCE, minimal scope requests, and proper credential revocation.
Audit Logging
All security-relevant events are captured in an immutable audit log, including:
- Notification delivery attempts (success and failure)
- Notification channel creation and deactivation
- Provider integration configuration changes
- API key creation and revocation
- Team member access changes
- Dashboard login events
Audit log retention varies by plan tier (7 days for Free, 30 days for Pro, 90 days for Scale, configurable for Enterprise). Audit logs are available through the dashboard and API.
Responsible Disclosure
If you discover a security vulnerability in Chimatic, please report it to security@chimatic.dev. We ask that you:
- Provide sufficient detail for us to reproduce the issue
- Allow reasonable time for us to address the vulnerability before public disclosure
- Do not access or modify data belonging to other customers
We commit to acknowledging reports within 24 hours and providing an initial assessment within 72 hours. We do not pursue legal action against researchers who follow responsible disclosure practices.
Open Source Transparency
The Chimatic notification delivery engine is fully open source. This is a deliberate architectural decision: the component that handles your most sensitive notification data should be auditable by your security team.
You can review the delivery engine source code, run your own security audits, and verify that notification data is handled exactly as we describe on this page. We believe transparency is the strongest foundation for trust when it comes to notification orchestration.
The React SDK, Node.js SDK, and Python SDK are also open source under the MIT License, giving you full visibility into how notification data flows between your application and Chimatic.