> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tied.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Account lifecycle

> Current signup and workspace deletion behavior.

Account creation follows the [public signup contract](/api-reference/authentication#account-creation-uses-the-signup-contract). It is not an account-scoped integration operation. There is no owner-change API route.

## Request deletion

An account administrator can send `POST /api/v1/accounts/{account_id}/workspace_deletion` with top-level `reason` and optional `feedback`. Both are trimmed; a missing or blank reason returns `422` with `{"error":"Reason is required"}`. A nested `workspace_deletion` object does not substitute for the top-level fields.

The non-enterprise service persists a deadline seven days after the request and deletion metadata. Repeating the request resets that deadline. The request does not synchronously delete anything. Scheduled cleanup selects expired markers and queues an account purge; the deadline is eligibility for asynchronous cleanup, not a guaranteed execution time. Account deletion encompasses account-owned records such as conversations, contacts, inboxes and messages through model deletion associations; independent financial, compliance and retention policies are not promises of erasure by this endpoint. Enterprise lifecycle extensions are outside this source review.

## Cancel deletion

An account administrator can send `DELETE` to the same route. Success returns `{"message":"Workspace deletion cancelled"}`, including when nothing was scheduled. Cancellation clears the marker, marker reason, workspace deletion reason and feedback, preserving unrelated account attributes.

**Today cancellation also succeeds at and after the deadline while the account exists.** [ENG-5879](https://linear.app/tied/issue/ENG-5879) owns the missing deadline refusal. Cancellation cannot restore a purged account or guarantee stopping deletion work already queued.

## Access and errors

Both operations require authentication, membership in the route account and the administrator role. An agent is refused even if they belong to the account; there is no separate owner-only check. An administrator of another account cannot mutate the route account. Unauthenticated requests return `401` with `errors[]`; role, membership and suspension failures return `401` with `error`. A trial-expired write lock returns `402`. Controller/service failures return `422` with `error`.

The prepared register proposals classify both operations as destructive with the `workspace_deletion` opt-in group, MCP hidden and SDK excluded. Those proposals are unapproved. Connector opt-in, fresh sign-in and second-administrator approval are future safeguards, not current runtime checks.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.