What we hold, and how
Because the platform runs against your provider account, it has to hold credentials that can send messages on your behalf. That makes how those credentials are stored the most important thing on this page.
Provider credentials
- Sealed with authenticated encryption. Credentials are encrypted with AES-256-GCM. The mode is authenticated, so a tampered ciphertext fails to decrypt rather than yielding a corrupted plaintext.
- A fresh initialisation vector per record. Each encryption generates a new 12-byte random IV, so two connections with identical credentials do not produce identical ciphertext.
- Rotatable master key. The ciphertext carries the key version it was sealed under, which means the master key can be rotated without first re-encrypting every stored record.
- Secrets are not echoed back. After a connection is saved, the console shows a short fingerprint derived from the credential rather than the value itself. You can tell that something is configured and that it changed, without the plaintext being sent to a browser.
What a delivery record contains
The record for a sent message holds delivery metadata: the recipient, the provider and connection used, the status, the normalised error code, the raw provider status, the encoding and the billable segment count, and a retention deadline.
- Message bodies are not stored. There is no field holding message content on any plan. The record is about what happened to the message, not what the message said.
- Log retention is bounded. Each record carries an expiry derived from the retention period of the plan, so retention is a property of the data rather than a cleanup job somebody has to remember to run.
- Recipient addresses are masked in operational logs. Diagnostic logging shows a masked form of the address. To trace a specific recipient you use the console or an export, not the log stream.
Tenant separation
Every record belongs to a tenant, and queries are scoped to the authenticated tenant rather than filtered after the fact. Cross-tenant access to a record by id returns not-found rather than forbidden — a forbidden response would confirm that the record exists, which is enough to enumerate other tenants’ data.
Callback endpoints
Providers deliver delivery receipts and inbound replies to endpoints authenticated with a per-tenant webhook token. The token is carried in the URL query string because providers cannot be made to send a custom header on a callback.
We rely on that token rather than verifying a provider-issued request signature. Signature verification is on our hardening list and is not something we claim today.
What we do not claim
- No security certification is held or claimed on this site
- No dedicated compliance regime is claimed for any particular destination country
- No provider-request signature verification on callback endpoints
- No independent audit report is published
If a specific control is what your evaluation depends on, ask us directly and we will tell you exactly what is implemented. A security page that only lists strengths is not useful for a decision, and we would rather answer the hard question than round it off.