Nango is designed with security as a core principle. This page covers how credentials are stored and encrypted, how to authenticate with the Nango API, and compliance certifications.
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 → |
Credential storage
Nango stores the credentials required to act on behalf of your users with external APIs:
- OAuth tokens: Access tokens, refresh tokens, and associated metadata
- API keys: For APIs that use key-based authentication
- Client credentials: OAuth client IDs and secrets for your integrations
- Connection configuration: OAuth scopes, authorization parameters, and provider-specific settings
On Nango Cloud, all data is stored in AWS Aurora PostgreSQL with encryption at rest, automated backups with point-in-time recovery, multi-AZ deployment for high availability, and network isolation within a private VPC.
Encryption
Encryption at rest
All sensitive credentials are encrypted before being written to the database using AES-256-GCM.
| Property | Value |
|---|
| Algorithm | AES-256-GCM |
| Key size | 256 bits (32 bytes) |
| IV size | 12 bytes, generated per encryption operation |
| Auth tag size | 16 bytes |
- Connection credentials (OAuth tokens, API keys)
- OAuth client secrets
- Environment secret keys
- Environment variables
Encryption in transit
All data transmitted to and from Nango is encrypted using TLS 1.2+, including API requests from your application, requests from Nango to external APIs, and dashboard access.
Key management
On Nango Cloud, encryption keys are managed by Nango — all credentials are encrypted at rest automatically.
On self-hosted deployments, you provide your own encryption key via the NANGO_ENCRYPTION_KEY environment variable. Without this key, credentials are stored unencrypted.
# Generate a 256-bit base64-encoded key
openssl rand -base64 32
The encryption key cannot be changed after it is set. Changing the key after initial setup will cause decryption failures for all stored credentials. Plan your key management carefully before deploying.
API authentication
Secret key vs. public key
Each Nango environment has two keys with different trust levels:
| Key | Use case | Where to use |
|---|
| Secret key | Server-to-server API calls, SDK initialization | Backend only — never in client-side code |
| Public key | Initiating OAuth flows via the frontend SDK | Frontend — safe to expose in the browser |
| Connect session token | Short-lived token for frontend auth flows | Frontend — expires after 30 minutes |
Authorization header:
Authorization: Bearer <your-secret-key>
Rotating keys
If a secret key is compromised, rotate it immediately from Environment Settings in the dashboard. The old key is invalidated instantly. Update your environment variables before rotating to avoid service interruption.
Environment isolation
Each environment (dev, prod, etc.) is completely isolated. Separate connections, separate credentials, and separate secret keys mean your production data is never accessible from development environments.
All credential access and modifications are logged — connection creation and deletion, token refresh operations, and API requests are all captured in the Logs tab.
Data retention
Credentials are stored as long as the connection exists. When you delete a connection:
- The connection is immediately soft-deleted and becomes inaccessible.
- Associated syncs are stopped and scheduled tasks are cancelled.
- Credentials and associated data are permanently removed after 31 days.
The 31-day window allows recovery from accidental deletions and supports in-flight operations. You can delete connections at any time via the dashboard, API, or SDK.
For GDPR data purge requests, contact Nango support to expedite deletion.
IP allowlist
If your customers’ systems restrict inbound traffic by IP address (e.g., firewalls, private APIs), allowlist the following Nango IP addresses:
52.34.139.15354.69.127.18344.247.133.18352.26.211.56
These are the public IPs Nango uses when making outbound requests to external APIs on behalf of your integrations. If a system is publicly accessible without IP restrictions, no allowlist configuration is needed.
IP addresses may change over time as Nango scales. Review this list periodically and ensure all listed IPs are allowlisted to minimize disruption.
Rate limiting
The Nango API enforces rate limits to ensure platform stability:
| Plan | Requests per minute |
|---|
| Free tier | 200 |
| Starter | 1,000 |
| Growth | 2,000 |
| Enterprise | Custom |
