Workspaces and accounts

Use one workspace for one project or business. A workspace holds that project's integrations, environments, members, credentials, observations, incidents, and audit history. For example, an ATS business and an e-commerce business can each have a workspace. A member invited to one does not gain access to the other.

Workspace boundary

Each workspace has its own membership and service credentials. Integration data and evidence stay within that workspace. New workspaces contain Sandbox and Live. Existing workspaces retain their Development, Staging, and Production environments until reviewed migration; those environments are not separate workspaces. An integration represents one external workflow within a workspace.

You can belong to workspaces funded by different accounts. The switcher lists workspaces you can access, regardless of which account funds them.

Test and Live views

Use the Test mode switch in the console header: off and gray selects testing; on and blue selects Live. A bright amber banner with dark text identifies testing and the exact selected environment at the top of the screen, above the sidebar and header. A full-page progress animation covers mode changes until the new data is ready. During migration, Development and Staging map to testing, and Production maps to Live. Existing Staging links stay scoped to Staging. The selection changes your view; it does not move data, provision connections, or change billing. Notifications and workspace settings apply across modes. Read the environment guide.

In canonical workspaces, one integration has independent Sandbox and Live connections. Owners and admins can set up a missing connection from the Integrations list. Start empty or use reviewed configuration copying from the other mode: select declared contracts and rules, review the preview, then apply it. Copied contracts start as drafts and copied rules are disabled. Credentials and observed history stay separate, and later configuration changes do not synchronize automatically. Set up the other mode.

Setup reviews last ten minutes and cannot complete after expiry. Applying or reading a review requires its original, currently authorized owner, admin, or workspace API key. A completed receipt records past setup and contains no reusable token; it does not prove current connection health.

Existing-workspace conversion remains a reviewed migration. Account mode accounting records Sandbox and Live separately. Sandbox defaults to 10,000 accepted observations per UTC month, with enforcement initially off. The Sandbox policy begins only after publication and a grace period. Live usage includes historical usage that cannot be classified; its remaining plan allowance is informational. Activating Sandbox enforcement does not reject Live observations or introduce overage charges. Read the account usage contract for effective dates.

Credential changes apply to one connection and require its reviewed revision. A permission change or key expiry during the operation rolls back the token change and its receipt. A retained credential receipt records what committed, contains no reusable token, and remains bound to the original authority. Completed canonical session receipts remain readable by the original user who is still an owner/admin after archival. This grants no new mutations or pending-preview access. Read the exact receipt boundary. If its connection was removed or changed, it becomes historical. Review a separate rotation to replace a lost token. Manage connection credentials.

Account plan

One account plan covers the workspaces owned by that account. Sandbox observations have their own allowance and do not consume the Live allowance. Accepted usage remains with the admission account after workspace moves or data deletion. New canonical Sandbox observations received after the retention cutover expire after seven days by default; older evidence and Live evidence keep their existing retention policy. Creating another workspace does not add a separate workspace charge. The account's plan allowances apply across its workspaces, and the mode usage read returns pooled Sandbox and Live counts without workspace identities. The separate billing usage view can show per-workspace contributions.

Developer includes up to three active workspaces per account. Starter, Pro, and Team include multiple workspaces without a published numeric workspace cap. Enterprise terms are contracted. Paid plans remain provisioned by invitation during early access; self-service checkout is not available.

Workspace membership does not grant account administration. An account owner or billing admin may create under that account. Someone invited only to a workspace can create their own first Developer account but cannot spend the inviter's account plan.

Create and switch

After verifying your email and signing in, open the workspace switcher and select Create workspace. Enter a name, choose the account when you administer more than one, review its shared observation usage, and submit. Seamward opens the new workspace after creation and emails a confirmation with a link to the person who created it. If activation fails, the workspace is still saved and the screen offers another attempt to open it. Email delivery failure does not undo creation.

The creation form shows when a Developer account has reached three active workspaces. A workspace owner who also administers its account can archive a workspace in Settings to free a slot. New ingestion and customer writes stop; history stays available. Restore an archived workspace from the switcher, or from the recovery screen when no active workspace remains. Restoring checks the account's current limit. Read the session API contract.

Connection removal and shared identity

A connection is the configured Sandbox or Live side of a shared Integration. Removing one connection permanently purges its operational data and runtime credential. The shared identity remains, even without any configured connection. The other mode's connection, credentials, and evidence remain; accepted usage totals and audit history also remain.

For example, removing Candidate webhook's Sandbox connection leaves its Live connection collecting observations. Adding a new Sandbox connection later starts with independent credentials and no restored history. Copying reviewed draft configuration does not restore the deleted observations or activate rules.

Whole-Integration deletion removes the shared identity and its authorized connections. The setup CLI and MCP deletion commands keep that meaning. Use the connection deletion API when the intended target is one mode, and review its exact mode and permanent impact first.

Existing connection configuration

When both mode connections already exist, the configuration copy API can add reviewed source contracts as drafts and rules as disabled definitions. It preserves the destination's active contract, credentials and evidence. Copies do not synchronize later edits.

Compensation requires a separate review and removes only the pristine artifacts created by the original copy. A later destination configuration change or runtime reference blocks it, including an edit restored to its earlier value. The operation receipts remain auditable. Owners and admins can open Manage this connection from an Integration, select contracts and rules, review the copy, and apply it. Use Review compensation on its completed receipt. Save the operation ID or page URL for status recovery.

Review account usage and keys

Open Usage and API keys from the account menu, then choose the account. This page works without an active workspace, including when all workspaces are archived. Account owners and billing administrators can review pooled Test and Live observations, the UTC reset date, effective retention and enforcement.

Create a named usage API key with an expiry. It has only account:usage:read access. Save its secret when shown; it cannot be retrieved later. If the creation response is lost, refresh the list, revoke the new key whose secret was not received, and create a replacement. Revocation immediately stops usage access. See the account API reference.

Sandbox resource limits

These account-wide limits apply across every workspace and plan in canonical Sandbox. Rotation, connection deletion and workspace moves preserve charges already attributed to the admission account.

A retry reuses the original operation and period. Failed validations count. Interrupted work predating persisted AI dispatch intent resumes deterministically without another provider call. Never-started work releases its reservation when canceled or removed. If AI is unavailable, exhausted, or its earlier response is uncertain, the repair can continue with deterministic generation and isolated validation. No uncertain paid call is automatically repeated. Metadata, approvals, audit records and accounting can outlive observations.

These Sandbox safeguards do not impose new Live rejection or automatic overage charges. Read the limits and recovery reference.