# Security and privacy

Minimize notification data, keep producer credentials server-side, and understand what the managed service must decrypt to provide inbox and filtering features.

## Data handling

Sensitive business fields are encrypted by the application before PostgreSQL persistence and tenant-owned access is account-scoped. The managed application holds the keys needed to render and filter the inbox; this is not a client-held-key design. Use TLS for requests and send only the context needed to recognize and act on an event.

- Good metadata is a bounded operational identifier, status, environment, version, or non-secret reference.
- Do not send passwords, session tokens, API keys, authorization headers, cookies, private keys, recovery codes, or raw payment credentials.
- Avoid personal data and full customer content when a pseudonymous identifier or dashboard link is enough.
- Treat notification titles, bodies, metadata, and action URLs as stored account data.

## Credentials and actions

Source API keys are high-entropy secrets shown once; the service stores a cryptographic digest for authentication. Actions accept only HTTPS and mailto URLs without embedded credentials. They are links, not arbitrary code execution, and the user chooses whether to open them.

- [Authentication](/docs/authentication)
- [Payload fields](/docs/notification-payload)