Press / to search

All documentation
docs Operate Account and team

Runs onWrit Cloud

team ▸ people and access

Users & teams

A workspace belongs to an organization. People join as members with a role, share workflows and resources, and the owner controls billing, BYO-AI and data-governance settings. This page covers the account itself, roles, SSO and SCIM, and how notifications are routed.

account ▸ profile

Registration & profile

Sign up with email and password, then verify your email — privileged actions stay locked until you do. Your profile holds your display name, avatar, locale and notification preferences.

Export & deletion

GET /account/export returns a machine-readable export of your account data. Deleting the account requires your current password, and what happens next depends on your role: a sole owner deletes the organization with it (a typed confirmation is required), while the owner of a multi-member organization must first transfer ownership to another member — or explicitly delete the entire organization.

See Privacy and the Data Processing Addendum for how data is handled, and sub-processors for who processes it.

roles ▸ one per member

Members & roles

Invite teammates by email. Each member has exactly one role:

RoleCan do
OwnerEverything, including billing, plan changes, BYO-AI and deleting the organization. One owner per organization; ownership is transferable, and the previous owner becomes a member.
AdminManage members, workflows, resources, monitors and endpoints. No billing-destructive actions.
MemberCreate and run workflows, monitors and automations within granted scopes.

Invitations and role changes can assign admin or member; ownership moves only through an explicit transfer.

sso ▸ domain-routed

SSO & domain verification

Single sign-on binds to a domain you prove you control: create a DNS TXT record at _writ-sso-verify.{domain} with the value the setup screen gives you. Once verified, sign-ins for that domain route to your identity provider. Two properties are worth knowing:

  • sso_enforced (optional): non-SSO logins for the domain are refused — password sign-in stops being an alternative door.
  • SSO discovery reveals routing only. Asking “how does this email sign in?” never discloses whether an account exists.

scim ▸ the roster, synced

SCIM provisioning

Organizations can provision members over SCIM 2.0 from an identity provider. Deprovisioning a user removes their membership, suspends the account if it is left with no membership at all, and immediately revokes any live sessions and tokens — offboarding in the IdP is offboarding in Writ, with nothing left signed in.

oauth ▸ capped

OAuth grants are capped

Access granted through an OAuth flow is capped at the operator role — however broad the requested scopes, an OAuth grant never carries admin. Administrative control stays with people who signed in as themselves.

notifications ▸ categories × channels

Notification preferences

Platform notifications are a grid: seven categories — security, billing, team, runs, agents, marketplace, support — across six channels: in_app, email, sms, whatsapp, signal, pushover. You choose per cell, with a deliberate exception: a few cells are locked always-on — security alerts, payment problems and team invites cannot be silenced.

org ▸ byo-ai

Organization & BYO-AI

Organization settings cover the workspace name, default agent routing and the AI provider mode. With bring-your-own AI, AI calls are served through an agent holding the organization’s own provider keys — the keys stay on that machine, and no managed AI is billed for those calls.

byo_ai_modeBehavior
offAI runs on Writ’s managed gateway; billed per token.
preferUse the org’s own keys when an agent holding them is online; fall back to managed otherwise.
strictOwn keys only: the AI call fails rather than falling back, so prompts never touch platform keys.

Writ runs on your own accounts, with your own credentials and data, on sites you are authorized to use. BYO-AI extends that to the model layer: your provider keys, your tokens. One boundary holds regardless of mode: AI selector-repair is a managed capability and never uses BYO keys — see Where it runs.

What next