Privacy friendly
Notifizz does not store your users’ personal data. Names, plans, segments, custom fields, profile graphs — none of it lives in the platform. When a campaign needs a recipient’s profile, the orchestrator fetches it live from your systems via an enricher, uses it to send the notification, and lets it go. The only customer data Notifizz retains is the strict minimum required to deliver the message and honour later requests (unsubscribe, right to erasure). That single rule — fetch live, don’t copy — is the core of the architecture. Everything below is what falls out of it: the email hashing story, the bounded cache, the redaction pass, the retention dials. None of it is a configuration option you opt into; it’s how the platform is wired.TL;DR
- No warehouse sync. Customer profiles stay in your systems. The orchestrator fetches what it needs at notification time via enrichers — never copies it.
- Plain email lives on a clock. It is held only inside an operational window (default 90 days, configurable down to 7) and purged after. What remains is a SHA-256 hash, scoped to your organisation — enough to de-duplicate and to honour a past unsubscribe, never enough to email again.
- Expired messages are redacted, not deleted. The personal data is emptied; the delivery record survives so your Outbox keeps telling the truth about what shipped.
- The enricher cache is bounded, not a sync. Per
(org, env, enricher, params)keying with a TTL declared at registration. Eviction is automatic; only recently used records exist. - Six retention dials, configured per organisation, with conservative GDPR-aligned defaults and platform-enforced minima.
Why it matters
GDPR Article 5 — and the equivalent regimes everywhere else — require you to hold customer data only as long as you need it, for explicit purposes. Notification platforms in the Customer.io / Braze / Iterable lineage centralise all customer data in their own database, indefinitely, in case a campaign ever fires for that customer. Your DPO ends up auditing a parallel customer graph that exists only for “we might send something one day”. Notifizz’s design eliminates that parallel graph. The privacy surface you have to audit is the event payloads you control, plus the per-message delivery snapshots — not a copy of every customer.The three pillars
1. Enrichers — no warehouse copy
The platform doesn’t sync your customer database. Instead, the orchestrator calls enrichers — server-side functions you register that fetch live data from your systems at notification time.- Privacy surface stays in your systems. Notifizz processes; you store.
- No drift. The user’s email is whatever your DB returns at notification time, not what last night’s sync ran with.
- No schema migration. New attribute? Add a field to the enricher’s output. Renamed? One file changes.
2. Email hashing — plain text only when needed
The platform handles email in two distinct states: plain during the operational window, hashed only outside it. The suppression list stores hashes only, so an unsubscribe survives forever without keeping the address forever.Normalisation, then hash
Every incoming email is normalised — trimmed and lower-cased — then hashed with SHA-256. The hash is scoped to your organisation: the same address in two different organisations produces two different hashes, so nothing correlates across customers of the platform. The hash is what makes the rest work. It de-duplicates a person arriving through several ingest paths, and it lets the platform recognise “this address unsubscribed” long after the address itself is gone.Plain email lifecycle
The plain email is held as long as a notification within the operational window references it — and purged automatically otherwise. When a new send arrives later for the same address, the hash matches the existing recipient, the plain email is reintroduced, and the history is continuous.
The window defaults to 90 days and is configurable per organisation. The platform enforces a 7-day minimum, below which bounce and complaint handling breaks — a feedback loop that reports on a send you no longer have an address for cannot be applied.
3. Cache — bounded, not a sync
Enricher responses are cached server-side to keep latency low. This is not a sync. The differences are structural:
Cache key is
(organisationId, environmentId, enricherName, sha256(params)) — strict cross-tenant isolation, identical params from different organisations never collide. TTL precedence: per-call override → declared at registration → 1-hour default. An enricher declaring cache: false cannot be overridden upward.
The enrichers protocol covers the cache policy in detail.
What Notifizz stores — and what it doesn’t
The cap is deliberate. You can’t ask Notifizz to “store the user’s plan” or “store the user’s segment”. The platform doesn’t have those columns. If a campaign needs them, an enricher fetches them on demand.
Retention configuration
GDPR places retention under the responsible-party (you, the controller) — not the processor (Notifizz). Notifizz exposes six configurable dials per organisation, with conservative defaults and platform-enforced minima:
The current configuration is the truth. A daily retention job re-applies the live dials to existing data; lowering one purges records that fall outside the new window. Lowering a dial surfaces a confirmation dialog showing the number of recipients impacted before applying — destructive changes are deliberate, not accidental.
All dial changes are logged in the audit trail (actor, timestamp, old → new, impacted count) — useful for CNIL / ICO inspections and for protecting both parties in a dispute.
Redaction
PastmessageRetentionDays, a sent message is not deleted. Recipient, address, rendered HTML, subject, properties and push payload are emptied; the row stays, flagged with a redaction timestamp. The emptied record is deleted in turn after 180 days.
The distinction is operational as much as legal. Deleting the row outright would take the delivery status, the campaign, the step and the timestamps with it — and a delivery report that finds nothing concludes that everything went fine, including for sends where not a single message ever left. A redacted record still says what happened. It just no longer says to whom.
The redaction flag is what separates a record that was emptied from one that never carried anything — without it, “absent” and “blank” would be indistinguishable, which is the exact trap the redaction pass exists to close.
In-app inbox messages are the deliberate exception: an inbox is a reading surface, so its entries are kept whole for notificationCenterRetentionYears and then deleted outright. A message someone is meant to read makes no sense emptied of its content.
Suppression and right to be forgotten
When a user unsubscribes, marks a message as spam, or asks to be deleted, the obligation is “never email again” plus (for deletion) “remove the record”. Notifizz handles both without keeping the address indefinitely:- Unsubscribe / spam complaint → the email is hashed, added to the per-org suppression list. Subsequent sends hash the incoming address and check the list before dispatch. The plain email is not retained.
- Right to erasure → declared by your system as part of your own user-deletion flow. Three routes, depending on what you are erasing:
There is no SDK shorthand for erasure today — call the endpoint directly from your own deletion flow.
How this composes with the rest
- Enrichers — the no-copy primitive, the largest contribution to the minimisation story.
- Recipients — recipients carry only
id+email(plus arbitrary fields you control); never absorbed into a profile store. - Authentication — widget auth modes keep authenticated and anonymous traffic strictly separated, in line with the CNIL January 2026 recommendation.
- Activity log — retention dial changes appear in the audit trail with full context.
FAQ
If you don't store profile data, how do you display a recipient's name in the dashboard?
If you don't store profile data, how do you display a recipient's name in the dashboard?
The dashboard fetches the live profile from a configurable per-organisation Profile Resolver webhook at render time — same model as enrichers, scoped to UI display. Names, avatars, CRM links, custom fields stay in your systems; Notifizz never persists them. If the resolver is unconfigured or unavailable, the UI falls back to the email or the truncated
external_id — display degrades, the platform doesn’t block.Why hash the email instead of just deleting it?
Why hash the email instead of just deleting it?
Because a user who unsubscribes today must not be re-emailed by a fresh campaign next year. The hash lets the platform recognise “this address has unsubscribed” without keeping the address itself. It also handles the case where the same person comes back through a different ingest path — the hash matches, the suppression applies, no email goes out.
Why is the hash scoped per organisation?
Why is the hash scoped per organisation?
So that nothing correlates across customers of the platform. The same address in two organisations produces two unrelated hashes — one organisation’s data can never be joined to another’s on the hash. A single global hash would make every Notifizz customer’s audience comparable to every other’s, which is precisely the parallel customer graph this architecture exists to avoid.
The enricher cache holds data — isn't that a sync I have to audit?
The enricher cache holds data — isn't that a sync I have to audit?
No. A cache stores records actually used in the last TTL window. A sync stores every customer indefinitely. The privacy footprint scales with notification volume, not with customer count, and evicts itself automatically. If you need stronger guarantees for a specific enricher (say, one that fetches sensitive fields), declare
cache: false at registration — the orchestrator will hit your endpoint on every call.What happens when I run a marketing campaign to 50,000 customers? You'd need their emails for hours.
What happens when I run a marketing campaign to 50,000 customers? You'd need their emails for hours.
During the campaign window, yes — the plain address is held in order to dispatch. Once the operational window expires (default 90 days) the plain addresses are purged and only hashes remain. The window is configured per organisation: shorten it if your policy calls for it, down to the 7-day floor that bounce handling needs.
Can I export everything Notifizz holds about a specific user?
Can I export everything Notifizz holds about a specific user?
Yes — the API exposes a structured export per recipient (delivery history, inbox, hashed and plain identifiers as applicable), suitable for satisfying a Right of Access or Right to Portability request. Note that a message already redacted returns its delivery record without its content: the export reflects what the platform still holds, not what it once sent.
GDPR puts retention on the controller — what's Notifizz's role exactly?
GDPR puts retention on the controller — what's Notifizz's role exactly?
Notifizz is the processor in the GDPR sense; you remain the controller. The retention dials are exposed precisely because the duration is your decision. Notifizz enforces minima (so a controller can’t ask the platform to break bounce handling or skip the legal suppression-list floor) and provides safe defaults, but the policy choice belongs to you. A model DPA is provided at onboarding.
See also
Why enrichers
The case against warehouse-sync platforms.
Enrichers protocol
Cache policy, HMAC, anti-replay — the wire spec.
Recipients
The minimal recipient shape and why it stays minimal.
Authentication
Auth modes that keep the authenticated / anonymous boundary strict.