Security and compliance in Default

Default has SOC 2 Type 1. Users sign in to Default through WorkOS, with single sign-on (SSO) or a one-time code sent to their email, and each member’s role limits what they can see and change. This page covers the security controls in the product and links to the pages that configure them.

SOC 2 and compliance documents

Topic	Where to find it
SOC 2	Default has SOC 2 Type 1.
Security questions	Email security@default.com.
Sub-processors	Default sub-processors lists the vendors Default uses to provide its services.
Privacy policy	Default privacy policy
Security overview	Default security

Default uses WorkOS to sign users in, and WorkOS hosts the sign-in page.

Single sign-on (SSO). When your workspace has an active SSO connection for a verified email domain, members with that domain sign in through your identity provider.
Email code. Default can send a user a one-time sign-in code by email.
Invitations. Admins add new members to a workspace by invitation. See Users.

Single sign-on (SSO) in Default

Admins set up SSO on the Single Sign-On (SSO) page in Settings, under Workspace Settings. Both steps run in the WorkOS Admin Portal, which Default opens in a single-use link that expires after about 5 minutes.

Verify a domain. Select Add domain and complete the DNS verification. The domain shows Healthy when it is verified.
Set up SSO. Select Set up SSO and connect your identity provider, such as Okta or Microsoft Entra. The connection shows Active when members can sign in through it.

Set up SSO stays disabled until at least 1 domain is verified. Members who sign in through SSO with a domain lose access when an admin removes that domain, so Default asks the admin to type the domain to confirm. See Single Sign-On (SSO).

User provisioning in Default

Default has no SCIM or directory sync. Admins add members with Invite People and remove them from Users, so joiners and leavers in your identity provider need the same change in Default. When Salesforce or HubSpot is connected, Add from Salesforce and Add from HubSpot import people to invite from your CRM. See Users.

Roles and permissions in Default

Every member has 1 role:

Role	What it allows
Admin	Access to all features and actions in the workspace.
Member	Specific access to selected features and actions in the workspace.
Viewer	Read-only access. Viewers cannot be granted edit access.

These settings pages are for admins only: Single Sign-On (SSO), API Keys, Webhook Secret, Organization, Notifications, Notification Domains, and Scheduling. Admins can connect any integration. Members can connect only their own calendar and conferencing tools. See Integrations. Some workspaces also enforce granular access grants. In those workspaces, the Users table shows a Permissions column, and admins assign permission presets with Grant access or Manage access. See Users.

API keys, webhooks, and MCP access

Access	How Default secures it
Public API keys	Admins create keys in Settings → API Keys. Each key is shown once, at creation, and carries only the permissions selected for it: `triggers:read`, `triggers:write`, `scheduling:read`, or `scheduling:write`. Default checks the key on every request, so a revoked key stops working right away. Each key is limited to 30 requests per minute.
Incoming webhooks	1 webhook secret per workspace authenticates every incoming webhook as a bearer token. Only admins can rotate it, and rotating stops the old secret immediately. See Webhook Secret.
MCP server (Beta)	AI clients sign in to Default through the browser, with no API key or token method. MCP tools require the admin or owner role, except the routing write tools, which follow the same queue permissions as the app: a member who can edit a queue in Default can change it through MCP. Write tools preview each change and commit only after confirmation. See MCP server.

The public API is server to server. It sends no CORS headers, so a browser cannot call it and the key stays on your server. See Route and book through the API.

Website visitor data and the Pixel

The Pixel is the script that captures form submissions on your website. It has fixed limits on what it collects:

Sensitive fields are dropped. The Pixel never sends the value of a field whose name contains password, secret, token, key, auth, credential, ssn, credit card, cvv, or cvc.
Files are never sent. File inputs are skipped entirely.
Some paths are skipped. Pages whose path contains /login, /signin, /account, /checkout, /oauth, or /admin/ are not captured.
You can turn capture off. A meta tag skips a whole page, and data-default-ignore skips a single form or region.
Consent is respected. Your consent banner can withhold analytics or marketing consent with setConsent. Tracking is allowed until a visitor withholds consent, and form submissions are always captured.

See Privacy and data handling for the full rules.

Integrations and outside providers

CRM and sequencing tools. Admins connect them from Integrations. Most open the provider’s own sign-in window, and a few, such as Apollo, ask for an API key. Disconnect removes the integration from the workspace.
Enrichment providers. Default supplies access to every enrichment and Website Intent provider, so you don’t need an account or API key with any of them. Turning a Website Intent provider off stops Default from using it for your visitors. See Enrichment providers.

When an event sends SMS messages to guests, the booking form shows SMS consent text below the phone field. Each booking-related text message is followed by a compliance message that explains why the lead received it and how to opt out by texting STOP. See Events.

Records of activity in Default

Record	What it shows
Run logs	Every workflow run: the trigger, the path it took, and what each node did.
Routing Assignments	The decision record for each assignment: the queue settings, every member’s score, and the member chosen. See Queue assignments.
Routing Activity	Changes to queues and their members. See Activity log.

​SOC 2 and compliance documents

​Sign-in to Default

​Single sign-on (SSO) in Default

​User provisioning in Default

​Roles and permissions in Default

​API keys, webhooks, and MCP access

​Website visitor data and the Pixel

​Integrations and outside providers

​SMS consent for leads

​Records of activity in Default