Nango is designed with security as a core principle. This page provides technical details about how Nango stores, encrypts, and manages API credentials.
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) automatically applies to all cloud accounts. View DPA → |
| HIPAA | Business Associate Agreement (BAA) available on request. Contact us → |
- Regular security assessments and penetration testing
- Secure development lifecycle
- Incident response procedures
- Continuous monitoring and alerting
Visit our Trust Center for the latest compliance documentation, security policies, and audit reports.
Credential storage
What credentials are stored
Nango stores the following credential types depending on your API integrations:
- OAuth tokens: Access tokens, refresh tokens, and associated metadata
- API keys: For APIs using key-based authentication
- Client credentials: OAuth client IDs and secrets for your integrations
- Connection configuration: OAuth scopes, authorization parameters, and provider-specific settings
Storage infrastructure
Nango Cloud stores all data in AWS Aurora PostgreSQL databases hosted in AWS. The database infrastructure includes:
- Encryption at rest using AWS-managed keys
- Automated backups with point-in-time recovery
- Multi-AZ deployment for high availability
- Network isolation within a private VPC
For self-hosted deployments, you control the database infrastructure and can apply your own security policies.
Encryption
Encryption at rest
All sensitive credentials are encrypted before being stored in the database using AES-256-GCM (Advanced Encryption Standard with Galois/Counter Mode).
| Property | Value |
|---|
| Algorithm | AES-256-GCM |
| Key size | 256 bits (32 bytes) |
| IV size | 12 bytes (generated per encryption) |
| Auth tag size | 16 bytes |
What is encrypted
The following data types are encrypted at rest:
- Connection credentials (OAuth tokens, API keys, etc.)
- OAuth client secrets (your integration credentials)
- Environment secret keys
- Environment variables
Key management
- Nango Cloud: Encryption keys are securely managed by Nango. All credentials are encrypted at rest.
- Self-hosted: You must provide your own encryption key to enable encryption at rest.
Encryption in transit
All data transmitted to and from Nango is encrypted using TLS 1.2+. This includes:
- API requests between your application and Nango
- Requests from Nango to external APIs (using each provider’s TLS configuration)
- Dashboard access
Data retention
Active connections
Credentials are stored for as long as the connection exists. You have full control over connection lifecycle:
- Create connections when users authorize integrations
- Delete connections at any time via the API or dashboard
- Connections can be programmatically managed through your application
Retention after deletion
When a connection is deleted:
- Immediate soft delete: Connection is marked as deleted and becomes inaccessible
- Associated data cleanup: Syncs are stopped, and scheduled tasks are cancelled
- Hard delete after retention period: Credentials and associated data are permanently removed from the database
The default retention period is 31 days. For self-hosted deployments, this is configurable.
This retention period allows for:
- Recovery from accidental deletions
- Compliance with audit requirements
- Graceful handling of in-flight operations
What is deleted
When a connection is permanently deleted, the following data is removed:
- All stored credentials (tokens, keys, secrets)
- Connection metadata and configuration
- Sync records associated with the connection
- Related job history and logs
Synced records retention
This section only applies if you are using Functions of type Sync, e.g. for replicating data or receiving trigger notifications from an external API.
Automated payload pruning (30 days)
If a record has not been updated for 30 days, Nango will automatically empty its payload.
Impact:
After pruning, the record’s data fields are no longer retrievable from the Nango cache via the API or SDK. However, Nango retains the metadata needed for change detection (record ID and payload hash). Your syncs will continue to work normally. This pruning does not impact sync execution or delta-detection capabilities.
Automated hard deletion (60 days)
If a sync has not executed for 60 days, all records belonging to that sync will be permanently deleted.
Impact:
Complete removal of all records from the inactive sync, including metadata and payload hashes used for delta-detection. The sync itself remains configured but starts fresh on the next execution. Nango will no longer be able to detect changes against previously synced records.
When do retention policies apply?
- 30-day pruning countdown: Starts from the last time a specific record was updated.
- 60-day deletion countdown: Starts from the last time a sync successfully executed.
Best practices
To work optimally with Nango’s retention policies:
1. Fetch records promptly
Set up webhooks from Nango to be notified when new data is available. Fetch the updated records immediately after receiving a sync webhook.
2. Use cursor-based synchronization
Track your sync progress using cursors to ensure you never miss records, even if webhooks are occasionally missed. Store the cursor of the last-fetched record and use it on subsequent fetches.
3. Store data in your own system
Don’t use Nango’s cache as your primary data store. Instead:
- Store synced records in your own database
- Use Nango as a synchronization pipeline
- Keep your own copy of all critical data
Longer retention requirements
If your use case requires accessing record payloads from Nango’s cache beyond the 30-day window, please reach out to the Nango team. We can work with you to ensure you don’t experience breaking changes.
Deletion procedures
User-initiated deletion
You can delete connections through:
- Dashboard: Navigate to the connection and click “Delete”
- API: Call the delete connection endpoint
- SDK: Use the
deleteConnection method in any of our backend SDKs
Automatic cleanup
Nango automatically cleans up:
- Expired OAuth sessions
- Expired connect session tokens
- Orphaned data from deleted integrations
Data purge requests
For compliance requirements (e.g., GDPR), contact Nango support to request immediate data purges. We can expedite the deletion process when required by regulation.
Access controls
API authentication
Nango supports multiple authentication methods:
| Method | Use case | Token lifetime |
|---|
| Secret key | Server-to-server API access | Long-lived (until rotated) |
| Connect session token | Frontend auth flows | 30 minutes |
| Session cookie | Dashboard access | Session-based |
Secret key security
- Secret keys are environment-specific (dev, prod, etc.)
- Keys can be rotated via the dashboard
- All API requests require a valid secret key in the
Authorization header
Environment isolation
Each environment in your Nango account is completely isolated:
- Separate credentials and connections
- Separate integration configurations
- Separate secret keys
This ensures your production data is never accessible from development environments.
Audit logging
All credential access and modifications are logged:
- Connection creation and deletion
- Credential refresh operations
- API requests using credentials
Logs are available in the Nango dashboard and can be exported via OpenTelemetry.
Team & roles
Nango supports multiple team members per account with role-based access control (RBAC). Roles determine what each member can view and modify, particularly in production environments.
Role overview
There are three roles:
| Full Access | Support | Contributor |
|---|
| Summary | Unrestricted access across all environments. The only role that can manage account settings, billing, and the team. | Designed for monitoring production without being able to change it. Full access in non-production environments. | Designed for developers who work exclusively in non-production environments. No production access at all. |
At least one Full Access member is required per account.
Permissions
| Full Access | Support | Contributor |
|---|
| Non-production: read (integrations, connections, syncs, logs) | ✓ | ✓ | ✓ |
| Non-production: write / delete | ✓ | ✓ | ✓ |
| Production: read (integrations, connections, syncs, logs) | ✓ | ✓ | — |
| Production: trigger syncs | ✓ | ✓ | — |
| Production: write / delete | ✓ | — | — |
| Production: view secret key | ✓ | — | — |
| Production: view integration credentials | ✓ | — | — |
| Production: view connection credentials | ✓ | — | — |
| Invite / update / remove team members | ✓ | — | — |
| Manage billing & plan | ✓ | — | — |
| Configure Connect UI | ✓ | — | — |
| Create environments / toggle production flag | ✓ | — | — |
All environments appear in the dashboard switcher regardless of role, but access is enforced server-side — users are blocked from entering environments their role does not permit. Permissions cannot be bypassed by manipulating URLs or API parameters.
Production environment flag
Whether an environment is considered production is configured in Environment Settings → General. The production status of the current environment is also visible in the environment dropdown at the top left of the dashboard.
The flag can be set on any environment regardless of its name — not just prod. This lets you protect environments like prod-eu, production, or live the same way.
Only Full Access members can toggle this flag. Once set, Support members get read-only access (without sensitive credentials) and Contributor members lose access entirely.
The production flag currently governs role-based access. In the future it may also control additional environment traits to differentiate production-grade environments from development or staging ones.
These roles apply to dashboard access only. They do not affect API authentication — any caller with a valid secret key retains full API access regardless of their dashboard role.
Single sign-on (SSO)
Nango Cloud uses WorkOS to power SSO.
Availability
| Plan | SSO support |
|---|
| Free / Starter | Google SSO only |
| Growth | SSO with 20+ identity providers (add-on) |
| Enterprise (Cloud) | SSO with 20+ identity providers (included) |
| Enterprise (Self-hosted) | Not yet available (planned) |
Supported providers
Through WorkOS, Nango supports the main SSO providers, including Okta, Entra ID, OneLogin and 20+ other identity providers.
How to enable SSO
- To enable SSO for your account, contact the Nango team (on our shared Slack channel or the community).
- If you are on the Growth plan, we will subscribe your workspace to the SSO add-on.
- We will invite an admin from your company to complete the SSO setup flow.
Setup flow
During setup, your company admin can configure the domains allowed to sign in. User accounts are created automatically through just-in-time (JIT) provisioning.
How users log in
Once SSO is configured, users sign in through your company’s identity provider (IdP). Nango currently does not provide a dedicated SSO button on the login page — login must be initiated from the IdP side.
IP Allowlist
Some integrations require network-level access controls that only allow inbound traffic from known IP addresses.
This page lists the public IP addresses used by Nango services when making outbound requests.
When is IP allowlisting required?
IP allowlisting is only required if your customers’ systems restrict inbound network traffic.
Common examples include:
- Private or self-hosted APIs behind a firewall
- Enterprise systems that only accept traffic from approved IPs
- Third-party services with IP-based access controls
If a system is publicly accessible without IP restrictions, no allowlist configuration is needed.
Nango public IP addresses
Allowlist the following IP addresses to permit inbound traffic from Nango:
52.34.139.15354.69.127.18344.247.133.18352.26.211.56
IP address changes
While we aim to keep IP addresses stable, they may change over time as we scale or improve reliability.
To minimize disruption:
- Ensure all listed IPs are allowlisted
- Periodically review this page for updates
We will make reasonable efforts to communicate breaking changes in advance.
