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. 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

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. Self-hosted deployments run on infrastructure you control, and all retention periods are configurable when self-hosting.

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: Connections are retained until you delete them. Deletion runs in two stages:
  1. Soft delete (immediate) β€” the connection becomes inaccessible, its syncs stop, and scheduled tasks are cancelled.
  2. 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

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 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.
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!