Workspaces

A workspace is the shared home for a team’s Deepline work. It brings together members, Plays and runs, provider connections, secrets, data, and billing. Some API fields and CLI commands use organization or org for the same object. One person can belong to several workspaces. Each workspace has its own access and configuration. For example, a team can keep an internal testing workspace separate from a client workspace, with different credentials, data, and funding.

​

Workspace creation and access

Create another workspace when a team, customer, or environment needs its own configuration and data boundary. The dashboard, CLI org create, and SDK workspaces.create support this workflow. The CLI also selects the created workspace. Each new workspace still needs its own provider connections and funding. Workspace settings also control how people join. Invitations and configured verified-domain access connect a person to the team. The person’s membership then determines their role. Enterprise workspace owners and admins can configure supported OIDC or SAML single sign-on, including domain verification. The API reference and deepline org sso --help describe those controls.

​

People and roles

Members share the workspace’s available operations. Roles determine which workspace-wide settings they can change: The workspace’s team settings show members and invitations. Provider access also depends on authorization in the provider’s system. A Deepline admin role does not grant access to an unrelated CRM or advertising account. Roles do not replace approval for a particular outcome. A member may be able to call a CRM action, while the team still needs to approve the proposed record changes.

​

Select the workspace for each interface

The dashboard’s workspace selector changes the workspace shown in that browser session. An API key identifies one workspace for an application or CLI caller. An MCP connection uses the workspace authorized for that connection. These are separate sessions. Switching the dashboard does not retarget an already configured application or agent. Verify the effective workspace before using customer data or starting provider work. The CLI can bind a project folder to a workspace. Separate folders can therefore serve different teams or customers. Process environment credentials take precedence over a saved folder binding. Choose a workspace for each project explains selection and verification.

​

API keys

A Deepline API key authenticates calls to Deepline. It is different from a provider API key, which authorizes access to that provider. Verified workspace members can create their own Deepline API keys in API keys. Keys belong to a member and workspace. The member’s current access determines available operations. Members can manage their own keys, while owners and admins can manage other members’ keys where the control permits it. Use separate keys for independently operated callers, such as an agent session and a production integration. Keep key values in trusted secret storage. Key rotation or revocation affects callers using that key, so update those callers and verify their access. The API reference documents authenticated application access. Agent interfaces explains the CLI, SDK, and MCP relationships.

​

Provider connections and secrets

A provider connection gives workspace operations access to a provider account. Owners and admins connect, update, enable, disable, or disconnect integrations. Members can use available connections when the selected action permits it. The connection’s provider scopes still limit what it can read or change. Some actions offer Deepline-managed access and need no customer connection. Other actions require your provider account. Connect integrations explains setup. Pricing and credits explains managed access and BYOK. Secrets hold private values used by authored Plays, such as an authenticated callback token. They have their own scope and management controls. Saving a secret does not connect a provider. A provider key in a local shell does not configure a hosted workspace connection.

​

Data and billing boundaries

Runs, saved results, and the Database are associated with the workspace used by the caller. Database explains where working data and retained results live. Sharing a data link or writing to a destination requires its own supported sharing or access mechanism. The workspace also owns its plan, credits, and Usage cap. Simultaneous users and applications consume that workspace’s funding. A separate workspace has separate settings. Switching workspaces does not transfer a balance or provider connection.

​

Notifications

Notifications connect workspace events to destinations. Groups combine event rules, email or Slack destinations, and delivery timing. A group can cover credit conditions, Play outcomes, or other supported events. Workspace participants can manage notification routes. This is separate from admin-only provider connection setup. For example, a Play failure rule can select all runs, scheduled runs, webhook-triggered runs, or a specific Play. Its configured failure threshold determines when it matches. Play runs explains the run states and evidence used for recovery. Email recipients can unsubscribe from a group’s messages. Slack delivery needs a connected workspace account and an accessible channel or member destination. The group’s rules, timing, enabled destinations, and recipient preferences determine delivery. A failed run is not a promise that every member receives email.