Snapshot 34838
Normalized text
Scripts and page chrome removed; this is what change detection compares.
Skip to main content Contact us if you have additional questions or if you require a security review for an Enterprise agreement. Compliance Nango is SOC 2 Type II certified, GDPR compliant, and HIPAA compliant. Certification Details SOC 2 Type II Annual audit covering security, availability, and confidentiality. View report → GDPR Data Processing Agreement (DPA) applies automatically to all cloud accounts. View DPA → HIPAA Business Associate Agreement (BAA) available with the Growth add-on → We run regular penetration tests, a secure development lifecycle, incident response procedures, and continuous monitoring. The Trust Center has our current policies and audit reports. Data storage, retention & deletion What Nango stores Data Includes Encryption Retention Connections Credentials, configuration, and metadata See Connections Until you delete the connection Integration credentials Your OAuth client secrets and custom provider settings AES-256-GCM Until you delete the integration Nango API keys Account and environment API keys AES-256-GCM Until rotated or deleted Environment variables Values you set per environment AES-256-GCM Until you delete them Synced records Record payloads written to the records cache by sync functions AES-256-GCM Payload 30 days, record 60 days Nango logs Auth flows, function executions, proxy requests Storage-level 15 days on Nango Cloud Audit trail Control-plane changes Storage-level 1 year by default Everything is encrypted at rest at the storage layer. Rows marked AES-256-GCM carry an additional application-level layer: the value is encrypted before it is written, so it stays unreadable to anyone holding database access alone. Data is stored in a managed PostgreSQL database in AWS, network-isolated in a private subnet, with automated backups and point-in-time recovery. BYOC deployments run in a cloud account you control, and all retention periods are configurable there. Encryption & key management Key management — Nango uses envelope encryption. A 256-bit data encryption key (DEK) performs the encryption and is itself stored only in wrapped form, encrypted under a key held in AWS KMS. Algorithm details — AES-256-GCM with a 256-bit key, a fresh 12-byte initialization vector per encryption, and a 16-byte authentication tag. GCM is authenticated, so a tampered value fails to decrypt rather than returning corrupted data. In transit — TLS 1.2+ on all traffic: your application to Nango, dashboard access, and Nango’s requests to external APIs. Connections A connection holds everything Nango needs to call an external API on behalf of one of your customers: Field Contents Encryption Credentials OAuth access and refresh tokens, API keys, other provider credentials AES-256-GCM Connection configuration OAuth scopes, authorization parameters, provider-specific settings Storage-level Metadata Customer-specific configuration you set through the API or SDK Storage-level Connections are retained until you delete them. Deletion runs in two stages: Soft delete (immediate) — the connection becomes inaccessible, its syncs stop, and scheduled tasks are cancelled. Hard delete (31 days later) — credentials, configuration, metadata, synced records, and job history are permanently removed. The window allows recovery from accidental deletion. Logs and audit trail entries age out on their own schedule. They are not removed when you delete a connection and remain until their retention window ends. Synced records Applies only if you use the records cache. Nango prunes the records cache so customer data is not held indefinitely: Payload pruning after 30 days without a record update. The record ID and payload hash remain, so change detection and your syncs keep working — but the data is no longer retrievable from the cache. Hard deletion after 60 days without a sync execution. All records data associated with this sync is deleted, including delta-detection hashes. If you start the sync again it starts with an empty cache. Treat the cache as a delivery mechanism, not a data store: fetch promptly and keep your own copy. Nango logs Nango logs are the operational record of what ran in your account: auth flows, function executions, proxy requests. They are exportable via OpenTelemetry. For proxy requests and API calls made from your functions, Nango records the URL, method, status code, and headers — never request or response bodies, so customer data flowing through an API call is not written to the logs. Headers are redacted before they are stored: Authorization always, plus the connection’s credentials and any other configured secret values. Credentials are also stripped from logged URLs. Audit trail The audit trail records control-plane changes with actor, outcome, and originating IP: who created or deleted a connection, changed an integration, rotated an API key, or signed in. Entries are immutable and account-wide, exportable as CSV. Data purge requests For compliance requirements such as GDPR, contact Nango support to request an immediate data purge. We can expedite deletion when regulation requires it. Access control API authentication Method Grants access to Lifetime Environment API key A single environment: integrations, connections, functions, records, proxy Long-lived, until rotated Account API key Account-level APIs only — never environment data Long-lived, until rotated Connect session token One end user’s auth flow, in one environment 30 minutes Session cookie Dashboard access Session-based See the API keys reference for key types, capabilities, scopes, and management. Environment isolation Each environment is fully isolated — separate credentials, connections, integration configurations, and API keys — so production data is never reachable from a development environment. Team roles (RBAC) Roles govern what each team member can see and change. Full Access Support Contributor Designed for Admins and production operators Monitoring production without changing it Developers working outside production Non-production: read, write, delete ✓ ✓ ✓ Production: read non-sensitive data, trigger syncs ✓ ✓ — Production: view API keys & credentials, write, delete ✓ — — Manage team, billing, environments ✓ — — Full Access is the default for just-in-time provisioning via SSO, and every account needs at least one. Manual invitations let you pick the role. Roles apply to the dashboard only. They do not affect API authentication: any caller with a valid API key retains the access that key grants. Single sign-on (SSO) Nango Cloud uses WorkOS for SAML SSO, supporting Okta, Entra ID, OneLogin, and 20+ other identity providers. Plan SSO support Free / Pay-as-you-go Google SSO only Growth add-on SAML SSO Enterprise (Cloud) SAML SSO + SCIM Enterprise (Self-hosted) Not yet available (planned) Nango has no SSO button on the login page — login must be initiated from your identity provider. Network access Allowlisting is only needed when your customers’ systems restrict inbound traffic — private APIs behind a firewall, or systems that only accept approved IPs. Publicly accessible systems need no configuration. Nango makes outbound requests from these public IP addresses: 52.34.139.153 54.69.127.183 44.247.133.183 52.26.211.56 These IPs may change as we scale. Allowlist all of them and review this page periodically; we will make reasonable efforts to announce breaking changes in advance. Vulnerability disclosure Security researchers can submit findings by following our security policy. We appreciate responsible disclosures! Related guides API keys - create scoped keys for production access. Auth guide - keep provider credentials out of your app. Token refreshing and validity - handle revoked OAuth credentials. BYOC - run a dedicated Nango instance in your own cloud account. Was this page helpful?