Privacy by Design means building data protection into a system’s architecture from the start, not patching it in afterward. For Nylas, this means least-privilege OAuth scopes, data minimization applied to what the platform processes, encryption in transit and at rest, and layered operational controls — applied to the email, calendar, contacts, and scheduling infrastructure Nylas provides. This page explains how those commitments work in practice and what responsibilities developers and organizations share when building on top of communications APIs.
What “Privacy by Design” means for a communications API
Privacy by Design, as a framework, holds that privacy protection should be built into systems architecture by default — not added after deployment in response to a breach or a compliance requirement. For a communications API, that framing has specific technical consequences.
Email, calendar, contacts, and scheduling systems handle data that is simultaneously personal and operational. A single inbox can contain employment records, healthcare scheduling, financial negotiations, authentication emails, and customer conversations. That means the access controls, retention policies, and data processing rules that apply to a communications API are not abstract governance questions. They determine what happens to sensitive data in production, at scale, across thousands of connected applications.
Nylas builds communications infrastructure used by software teams integrating email and calendar functionality into their products. Privacy considerations are present from architecture decisions — how OAuth scopes are structured, what data the platform retains, how permissions flow between connected systems — through to ongoing operations.
Core privacy principles
Data minimization
Nylas applies data minimization principles to the processing of customer data. This means evaluating what data is collected, what data is required for a given feature, how long data should be retained, and whether specific workflows can operate with reduced data exposure.
For communications systems, data minimization matters more than in most software categories. Email and calendar data often contains information that is sensitive in ways that are not obvious at the point of collection: scheduling metadata reveals work patterns, email thread history reveals business relationships, contact data reveals organizational structure.
The sensitivity of communications data often depends on context rather than data type alone. A calendar event or email subject line that appears routine in isolation may reveal confidential business relationships, merger activity, healthcare appointments, or legal matters when combined with other information.
Minimizing what gets processed, retained, and shared across integrations is not only a privacy practice — it reduces the operational risk associated with a breach, a misconfigured integration, or an unexpected vendor change.
Nylas also supports Privacy Mode for eligible contract plans, which can restrict calendar event access to events created using the Nylas APIs. When enabled, Privacy Mode helps limit access to application-created events rather than exposing all events in a user’s calendar through the API. This can be useful for applications where privacy, access management, or compliance requirements call for tighter control over which calendar events are accessible.
Least-privilege access
The most direct technical expression of privacy by design in a communications API is scope control. OAuth scopes define what an application can access: read-only vs. read-write, email only vs. full account, specific folders vs. the entire inbox.
Nylas uses scoped authentication and authorization controls to help limit access to the permissions required for a given integration or workflow. In practice:
An application that reads calendar availability to offer scheduling suggestions does not need access to email message bodies.
An application that sends outbound notifications does not need permission to read received messages.
An application that tracks email open rates does not need write access to the user’s contacts.
Developers building on Nylas should request only the minimum OAuth scopes their application actually requires. Overly broad scope requests increase the data footprint, expand the breach surface, and in regulated environments may trigger compliance review.
Common OAuth scope mistakes in email and calendar integrations:
Application need
Minimum required scope
Common mistake
Check calendar availability
Calendar read
Full account access
Send outbound emails
Email send only
Full inbox read/write
Sync contacts for CRM
Contacts read
Full account access
Read email subjects for categorization
Email metadata
Full message body access
Book appointments
Calendar read/write
Email read/write included
Encryption and secure transmission
Customer data processed through Nylas is encrypted both in transit and at rest using industry-standard encryption. This applies to email messages, calendar events, contact records, authentication tokens, and associated metadata.
Encryption in transit protects data as it moves between Nylas infrastructure, connected email providers (Google, Microsoft, Exchange), and the applications built on the Nylas platform. Encryption at rest protects stored data from unauthorized access at the infrastructure layer.
Encryption is a baseline, not a complete security posture. It operates in conjunction with access controls, monitoring, and vendor oversight — not as a substitute for them.
Access controls and authentication
Nylas maintains access controls restricting access to production systems and customer data to authorized personnel. Controls include role-based access restrictions, authentication requirements, multi-factor authentication, audit logging, and monitoring and review processes.
For developers building on Nylas:
OAuth tokens should be stored securely, not in plaintext configuration files or client-side code.
Token refresh logic should handle token expiration without requiring users to re-authenticate unnecessarily.
Token revocation should execute immediately when a user disconnects their account — not deferred to the next sync cycle.
Applications should log when OAuth tokens are used, refreshed, or revoked, to support audit and incident response processes.
Monitoring and operational safeguards
Operational monitoring supports the ability to identify unusual activity, investigate potential issues, and respond to security incidents. Nylas monitoring processes include logging and alerting, anomaly detection, security monitoring, vulnerability management, and infrastructure review.
For applications built on Nylas, monitoring at the application layer is a shared responsibility. Developers should log authentication events, access patterns, and error states in their own applications — not assume that platform-level monitoring covers the full picture of how their application behaves in production.
Vendor and subprocessor oversight
Modern communications infrastructure depends on cloud providers, identity providers, and related services. Nylas reviews third-party providers that support platform operations to evaluate relevant security and privacy risks.
For organizations evaluating Nylas as a vendor, the relevant question is not only what Nylas does with data, but also what providers Nylas relies on and what contractual and operational commitments govern those relationships. Organizations with specific questions about Nylas’s subprocessor relationships should contact Nylas directly.
Shared responsibility in communications API integrations
Privacy and security outcomes in a communications integration depend on both the platform and the application built on it. The Nylas platform provides infrastructure, controls, and documentation. Developers and organizations integrating communications APIs are responsible for how they configure and operate their applications.
Responsibility
Nylas platform
Developer / organization
OAuth scope infrastructure
Provides scoped permission model
Requests minimum scopes required
Token storage
Secure server-side token management
Secure client-side credential storage
Encryption in transit
Platform-enforced for all API calls
Application enforces HTTPS; never passes tokens in URLs
Data retention
Platform retention policies
Application-level retention and deletion policies
Access control
Role-based controls on Nylas infrastructure
End-user access controls within the application
Monitoring
Platform-level anomaly detection
Application-level access and error logging
Incident response
Nylas incident response for platform events
Application incident response for app-level events
OAuth revocation
Immediate token invalidation on disconnect
Application triggers revocation on user disconnect
Scope review
Scope model documentation
Periodic review of requested scopes vs. actual use
Calendar event access
Privacy Mode can restrict API access to Nylas-created events for eligible contract plans
Decide whether Privacy Mode is appropriate for the application’s privacy, compliance, and workflow requirements
The privacy outcomes users experience are shaped by both sides of this table. A platform with strong encryption and a well-designed OAuth model can still produce poor privacy outcomes if the application built on it requests excessive scopes, stores tokens insecurely, or never revokes access when users disconnect.
Developer checklist: privacy by design for email and calendar integrations
Before deploying an integration built on a communications API, developers should verify:
Scopes are minimum necessary. Review every OAuth scope the application requests. If a scope is not required for current functionality, remove it.
Tokens are stored securely. OAuth credentials are stored server-side, encrypted, and never exposed in client-side code, logs, or environment variable plaintext.
Token refresh is implemented correctly. The application handles token refresh without re-prompting users, and without failing silently when a token expires.
Revocation is immediate. When a user disconnects their account, the application revokes the OAuth token immediately — not at the next sync.
Data retention is defined. The application has a policy for how long email, calendar, and contact data is retained and what triggers deletion.
Access is logged. Authentication events, token use, and errors are logged in the application and available for audit review.
Subprocessors are understood. The developer has reviewed which third-party services their application sends communications data to and under what terms.
Shared responsibility is documented. The application’s privacy notice or terms of service accurately reflects what data is accessed, why, and how long it is retained.
Evolving privacy expectations
Privacy by Design is often associated with GDPR, but the underlying principles apply regardless of jurisdiction. Building least-privilege access, data minimization, secure authentication, and clear governance into a communications platform can improve security, reduce operational risk, and help organizations meet evolving privacy expectations across multiple regulatory frameworks.
Regulatory frameworks for data privacy, AI governance, and communications security continue to develop. Privacy expectations increasingly extend beyond traditional privacy regulations. GDPR, the EU AI Act, emerging US state privacy laws, sector-specific regulations, and customer procurement requirements all influence how organizations evaluate communications platforms.
As organizations connect more systems, vendors, and AI-enabled workflows together, the question of how data moves across those integrations becomes more consequential. A calendar event that touches an email API, a scheduling tool, a CRM, and an AI summarization service in a single workflow has moved through multiple data processors by the time the user sees a response.
Nylas continues to refine its privacy and security practices as regulatory requirements, customer expectations, and operational standards evolve. Organizations building on Nylas should also maintain their own review processes — both for how their applications use Nylas and for how the broader ecosystem they operate in handles the data their integrations touch.
Closing
Privacy by Design is an ongoing engineering and governance discipline rather than a one-time compliance exercise. Every decision about permissions, authentication, token management, data retention, monitoring, and third-party integrations influences how communications data is protected in practice.
For organizations building on communications APIs, effective privacy depends on both the platform and the application. Platforms can provide secure infrastructure, least-privilege access models, encryption, and operational safeguards. Developers and organizations determine how those capabilities are configured, what data is collected, and how privacy requirements are implemented within their own products and workflows.
At Nylas, Privacy by Design is reflected in the same principles that guide our broader security and governance programs: least-privilege access, data minimization, layered security controls, and transparency. As privacy expectations continue to evolve, we will continue refining those practices to help customers build communications experiences that are both powerful and privacy-conscious.
Frequently asked questions
What is Privacy by Design and how does it apply to communications APIs?
Privacy by Design is a framework, originally articulated by Ontario Information and Privacy Commissioner Ann Cavoukian, that holds privacy protection should be embedded into system architecture proactively rather than added after the fact. For communications APIs, this means structuring OAuth permission models to support least-privilege access, applying data minimization to what the platform collects and retains, encrypting data in transit and at rest by default, and documenting shared responsibility between the platform and the applications built on it.
Does Nylas encrypt email and calendar data?
Yes. Customer data processed through Nylas is encrypted both in transit and at rest using industry-standard encryption. This applies to email messages, calendar events, contact records, OAuth tokens, and associated metadata.
Does Nylas retain customer communications data?
Nylas may retain certain customer communications data as needed to provide, secure, support, and operate the services requested by customers. Depending on the services used, this may include email metadata or content, calendar events, contact information, authentication/OAuth tokens, API usage information, and support or operational data.
Nylas applies data minimization principles and retains personal information only as long as needed for the applicable processing purposes, subject to customer configuration, contractual terms, legal requirements, and platform operational needs.
What OAuth scopes does Nylas support?
Nylas provides a scoped OAuth permission model that allows applications to request only the access they need. Developers can request read-only access, write access, or access scoped to specific data types — such as calendar only, email only, or contacts only. Applications should request the minimum scopes required for their functionality. Full account access scopes should only be requested when the application genuinely requires full account access.
How should developers store OAuth tokens for email and calendar integrations?
OAuth tokens should be stored server-side, encrypted, and never exposed in client-side code, browser storage, plaintext logs, or plaintext environment variables. Applications should implement token refresh logic to handle expiration without user re-authentication, and should revoke tokens immediately when users disconnect their accounts.
What is the shared responsibility model for privacy in Nylas integrations?
Nylas is responsible for the platform layer: infrastructure security, encryption, OAuth scope infrastructure, token management, monitoring, and subprocessor oversight. Developers and organizations building on Nylas are responsible for the application layer: requesting minimum necessary scopes, storing credentials securely, defining data retention policies, implementing revocation on disconnect, and logging access events in their own applications.
How does data minimization work in the Nylas platform?
Nylas applies data minimization principles to what it collects and processes. The platform evaluates what data is required to provide requested functionality, how long data needs to be retained, and whether workflows can operate with reduced data exposure. Developers building on Nylas also contribute to data minimization by requesting only the OAuth scopes they need and defining retention and deletion policies for data their applications store.
Does Nylas support restricting access to calendar events?
Yes. Nylas supports Privacy Mode for eligible contract plans. When enabled, Privacy Mode restricts API access so users can access only calendar events created using Nylas, while events created outside Nylas are not accessible through affected event endpoints and do not trigger event webhook notifications. Organizations should evaluate whether Privacy Mode fits their application’s privacy and access-control requirements before enabling it, because events created before Privacy Mode is enabled become inaccessible through the privacy filter.
Does Nylas comply with GDPR?
Organizations using Nylas to process personal data belonging to EU residents should evaluate their own GDPR obligations as data controllers. Nylas acts as a data processor in the context of the communications data processed through the platform. Organizations should consult legal counsel regarding their specific GDPR obligations and review Nylas’s data processing terms for relevant commitments. Nylas does not make generalized claims that using the platform automatically satisfies GDPR or any other regulatory requirement.
What should developers do when a user requests deletion of their data?
When a user requests deletion, the application should: revoke the user’s OAuth token through the Nylas API to terminate ongoing access, delete any email, calendar, or contact data the application has stored from that user’s account, and confirm the deletion with the user. Applications should have a documented data deletion process before deploying a production integration, not after receiving a deletion request.
How does Nylas handle subprocessors?
Nylas reviews third-party providers that support platform operations to evaluate security, privacy, operational, and contractual risks. Organizations requiring specific information about Nylas’s subprocessor relationships should contact Nylas directly. Organizations should also review and document the subprocessors involved in their own applications, particularly when those applications send communications data to third-party analytics, AI, or enrichment services.
What privacy questions should developers ask before choosing a communications API?
Developers evaluating communications APIs for privacy should ask: What OAuth scopes does the platform support and how granular are they? Does the platform encrypt data in transit and at rest? What is the platform’s data retention policy? Does the platform use customer data to train AI models? What are the subprocessor relationships and what commitments govern them? Is there a documented shared responsibility model? How quickly does the platform revoke OAuth tokens on disconnect? What logging and audit capabilities does the platform provide?
Email and Contacts API 
Calendar API & Scheduler 
Notetaker API 
Agent Accounts 
Sales & CRM 
Recruiting & ATS 
Healthcare
Financial
Legal
Real Estate
Education
Field Services
Docs
SDKs
Guides
Integrations
API status
Changelog
Support
Enterprise
