Loading...
Loading...
Bi-weekly engineering deep dives on auth, notifications, and developer infrastructure. No spam.
Sign Up for UpdatesPublished by Zyphr
A "Right to be Forgotten" request—better known as a Data Subject Request (DSR) under GDPR—usually lands in your inbox on a Monday morning when your sprint capacity is already maxed out. The legal team forwards an email, and the clock starts: you have 30 days to identify, extract, and purge every trace of a specific human being from your infrastructure. Failure to do so isn't just a bug; it is a statutory violation that can lead to percentage-based revenue fines. This is where saas compliance notification data management becomes a critical engineering hurdle rather than a simple database task.
If you are a CTO or an engineering manager, your first instinct is to look at your primary application database. You run a DELETE FROM users WHERE id = $1 and assume you have fulfilled the request. You haven't. You have barely scratched the surface. The real nightmare is the fragmentation of User PII (Personally Identifiable Information) across your entire stack. It is not just in your Postgres instance; it is scattered across your identity provider, your email gateway, your SMS vendor, your push notification service, and whatever socket-based in-app inbox you've built.
This is the "compliance tax." When you build a notification stack by gluing five different vendors together, you aren't just paying five separate invoices. You are incurring a massive operational burden. Every hour your senior engineers spend writing cleanup scripts for third-party APIs is an hour stolen from your product roadmap. As your user base scales, this fragmented data sprawl becomes a liability that cannot be ignored.
Take a look at the "standard" high-growth SaaS stack. You likely use Auth0 for identity, SendGrid for transactional emails, Twilio for SMS, Firebase Cloud Messaging (FCM) for push, and maybe Pusher or a custom-built solution for in-app notifications. To these vendors, a "user" is not a unified entity; they are a collection of disconnected attributes stored in isolated silos.
In your identity provider, the PII is obvious: names, emails, and hashed passwords. But as you move down the stack into the messaging layer, it gets murkier. SendGrid stores the recipient's email address in its activity logs, along with their IP address and precise location data gathered from open/click tracking. Twilio stores phone numbers and the literal plaintext content of MFA codes or alerts in their delivery logs. FCM and APNs (Apple Push Notification service) store device tokens, which are legally considered PII because they can be used to track and identify a specific device over time.
The "glue code" that connects these services is often the biggest security hole. To ensure SendGrid knows who to email, you are likely syncing user metadata via webhooks or cron jobs. This means you are constantly passing unencrypted PII between different environments, increasing the surface area for a potential breach. If one vendor has a data leak, you are on the hook for the entire chain of custody. You can read more about the related cost post to understand why this fragmentation is a ticking time bomb for your engineering team.
Deleting a user from your primary database is the easy part. The trap is the technical debt involved in purging their data from the rest of your vendors. Most developers realize too late that "Delete User" in a dashboard does not always translate to "Delete all logs and metadata" across five different APIs.
To truly comply with a DSR, you have to navigate five different dashboards or, more likely, write an orchestration script to hit five different APIs. Each vendor has its own rate limits, its own authentication scheme, and its own definition of what "deleted" means. Some might immediately purge the record; others might move it to a "soft-deleted" state that remains in their logs for 90 days—which could still put you in violation of certain strict privacy agreements if those logs aren't specifically scrubbed.
Consider what a "cleanup" script looks like when you are managing multiple vendors. It is brittle, it is hard to test, and it is prone to silent failures that leave you legally exposed.
import { Auth0Client } from 'auth0';
import { MailService } from '@sendgrid/mail';
import { Twilio } from 'twilio';
async function purgeUserEverywhere(userId: string, email: string, phone: string) {
try {
// 1. Remove from Identity Provider
await auth0.users.delete({ id: userId });
// 2. Remove from Email Provider
// Note: Deletion is often asynchronous and might require polling
await sendgrid.request({
method: 'DELETE',
url: '/v3/marketing/contacts',
body: { emails: [email] }
});
// 3. Redact SMS logs
// You have to iterate through message sids to actually redact PII
// because Twilio retains logs for 13 months by default.
const messages = await twilio.messages.list({ to: phone });
for (const msg of messages) {
await twilio.messages(msg.sid).update({ body: '' });
}
// 4. Update Push tokens
// You must manually manage these tokens in your own DB first
await myDatabase.pushTokens.deleteMany({ where: { userId } });
console.log(`User ${userId} purged across 4 vendors.`);
} catch (error) {
// If this fails at step 3, your user is in a "partially deleted"
// state. This creates a ghost profile that is a liability.
console.error('Purge failed halfway through:', error);
throw error;
}
}
This script is a maintenance liability. If Twilio changes its API version or SendGrid introduces a new rate limit, your "Right to be Forgotten" process breaks without anyone noticing. Leftover "orphaned data" in a delivery log is exactly what triggers hefty fines during a privacy audit. Furthermore, most of these APIs don't offer atomic transactions. If your script fails at step four, your system is now in an inconsistent state where the user is "gone" from your app but their PII still lives in your SMS logs.
If your customers are in the EU, you are dealing with the complexity of Data Processing Agreements (DPAs) and Standard Contractual Clauses (SCCs). When you use five different vendors, you aren't just signing one DPA; you are signing five. You are also responsible for ensuring each of those vendors handles data residency correctly according to the latest legal precedents like Schrems II.
Enforcing EU-only data residency is nearly impossible when your SMS provider routes messages through US-based carriers or your Push provider caches notification payloads on global edge servers. You might think your data stays in eu-central-1, but your notification metadata is likely hopping across three different continents before it reaches the user's phone.
Zyphr addresses this by providing granular data residency controls. Because we unify the identity and messaging layers, you can localize user profiles and delivery logs in a single region. You don't have to wonder if a stray email log is sitting on a server in Northern Virginia when your customer specifically requested their data stay in Frankfurt. This unified approach is a core part of security and compliance.
During a security audit or a legal dispute, you might be asked to prove "Notice and Consent." You need to show exactly when a user was notified of a change in terms and whether they received that notification. If your logs are fragmented, reconstructing this history is like trying to solve a puzzle with half the pieces missing.
Your email logs are in SendGrid with one timestamp format; your SMS logs are in Twilio with another; and your in-app notifications are buried in a custom Postgres table. Matching these records requires an "attribution gap" analysis—trying to correlate a user_id from your system with an internal sid from Twilio and a msg_id from SendGrid.
When your auth, email, SMS, and push live in one ecosystem, you get a single, immutable audit trail. You can see the entire lifecycle of a user’s interaction: they logged in, received a welcome email, verified their phone, and saw a notification alert—all under one ID, in one timeline, with one source of truth. This makes SOC 2 and ISO 27001 audits significantly faster and less painful for your engineering team.
We built Zyphr to end the "glue code" era of SaaS infrastructure. By combining authentication with multi-channel messaging, we eliminate the need to sync PII across disparate systems. The core of this is the Zyphr Subscriber API. Instead of managing device tokens for FCM, email addresses for SES, and phone numbers for Twilio, you manage one Subscriber profile.
When you want to delete a user, you call one endpoint. Zyphr handles the cascading deletion across all channels, logs, and metadata instantly. This is an atomic operation. You don't have to worry about a partial failure leaving an orphaned email address in a marketing list.
Furthermore, Zyphr provides a Unified Preference Center. One of the biggest compliance risks is the "phantom notification"—a user unsubscribes from emails via SendGrid, but because your SMS system doesn't know about it, they keep receiving texts. This is a fast track to a TCPA (Telephone Consumer Protection Act) violation. With Zyphr, an opt-out on one channel automatically updates preferences across all channels according to your defined business logic.
Here is how you can retrieve a full audit trail or purge a user using the Zyphr SDK:
import { Zyphr } from '@zyphr/sdk';
const zyphr = new Zyphr(process.env.ZYPHR_API_KEY);
async function handleCompliance(userId: string) {
// 1. Get a unified history of every message sent to this user
// across Email, SMS, Push, and In-App.
const { data: auditTrail } = await zyphr.subscribers.getAuditTrail(userId);
console.log(`User has received ${auditTrail.length} total communications.`);
// 2. Execute a full "Right to be Forgotten" deletion.
// This wipes the subscriber profile, their message history,
// and their auth credentials in one atomic operation.
await zyphr.subscribers.delete(userId);
console.log('User PII purged from all communication channels.');
}
Because Zyphr’s auth events automatically trigger their corresponding messages, there is no sync logic to maintain. When a user is deleted from the auth system, their notification footprint disappears simultaneously. No orphaned logs, no forgotten device tokens.
The first step toward a more secure platform is admitting how much PII you have actually leaked into your vendor logs. We recommend performing a "Data Surface Area Audit" this week. List every vendor that touches a user's email, phone number, or device ID. Then, ask your lead engineer for the "Time-to-Delete" metric: if a DSR arrived right now for your most active user, how many manual steps and how many different APIs would it take to actually purge their data?
If that answer involves more than one API call or a "we will have to check the logs manually," you are sitting on a compliance debt that will only get more expensive as you grow. Consolidation isn't just about saving money—it is about de-risking your platform's future.
Stop acting as a middleman for your own user data. Review our API documentation to see how you can unify your identity and messaging layers today and automate your compliance workflow.