Runs onWrit Cloud
On this page
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:
| Role | Can do |
|---|---|
| Owner | Everything, including billing, plan changes, BYO-AI and deleting the organization. One owner per organization; ownership is transferable, and the previous owner becomes a member. |
| Admin | Manage members, workflows, resources, monitors and endpoints. No billing-destructive actions. |
| Member | Create 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_mode | Behavior |
|---|---|
off | AI runs on Writ’s managed gateway; billed per token. |
prefer | Use the org’s own keys when an agent holding them is online; fall back to managed otherwise. |
strict | Own 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
- Personas, secrets and agents: what your team shares.
- Billing & usage: the one-pool model and who pays.
- Authentication: API keys, scopes, rotation.