Strengthening Our Security Posture with Environment-Restricted API Keys

We're introducing API Keys with Environment Restrictions, a direct extension of our least-privilege approach to integrations.

This strengthens our position as the most security-forward platform by giving teams clearer control over how developers access production, staging, and sandbox environments.

This feature came from customer feedback, including teams that needed a simple way to separate production access from non-production access for their developers without creating multiple workspaces or managing keys manually.

Why we built this

Customers told us:

• They wanted a clean way to give certain developers access only to non-production environments.
• They needed tighter control over production access for compliance and internal review.
• They didn't want to maintain multiple workspaces just to separate environments.
• They wanted a straightforward way to prevent accidental data access in their customer's connections on their production environment.

Environment-restricted keys solve that without changing the existing setup.

How it works

• You can optionally assign an API key to a specific environment (production, staging, or sandbox, or any custom environment) when assigning a key to a specific developer.
• Keys only operate within the environment they're scoped to.
• Existing keys remain unchanged unless you choose to apply restrictions.
• This reduces accidental access, limits blast radius, and aligns Unified access with your internal environment structure.

This is an optional feature — you can enable it when you need it.

Our broader security posture

Environment-restricted keys build on the controls we already provide across our platform. Unified is designed to safeguard customer data by default:

1. Zero customer data stored at rest

Unified operates on a passthrough, no-storage architecture. Data is fetched live, transformed, and delivered in real time. No customer records persist on our servers; only connection credentials and operational metadata are stored, encrypted at rest, and detailed logs are not stored.

1. Independent compliance

We have a SOC 2 Type II report and are compliant with GDPR, CCPA/CPRA, PIPEDA, and HIPAA. The absence of stored customer data reduces audit scope and removes PII persistence risk.

1. Encryption and secrets management

All data in transit uses TLS 1.2+. Connection credentials are encrypted at rest (privacy policy), and minimal operational metadata is encrypted at rest with AES-256. OAuth2 credentials and API tokens can be stored in your own secrets manager, including AWS Secrets Manager, Azure Key Vault, Google Cloud Secrets Manager, HashiCorp Vault, 1Password, Doppler and Bitwarden.

1. Access controls

Dashboard access can be enforced through SAML-based SSO with your IdP's MFA and conditional-access policies. Role-based permissions and IP allowlisting give teams further control.

1. Application security

Unified undergoes annual third-party penetration testing. Containers and infrastructure are continuously scanned, every build goes through SAST, and runtime is covered by DAST.

1. Segregated data regions

Customers can select US, EU, or APAC regions. Multi-region isolation ensures credentials and operational metadata stay within the region selected.

You can review all details or request reports through our Trust Center.

Environment-restricted keys extend this foundation, giving teams another layer of control without adding setup overhead. If you need guidance on how to roll this out across your team, reach out — we'll walk you through it.