Outcome
Permanently erase all Sign records and signing-document objects for the organization after an explicit ERASE confirmation. Completed envelopes and their audit certificates go with it, so executed agreements lose their evidence.
Before you start
- Verify the environment, authenticated identity and specifically approved organization context.
- The published application permission is privacy:write. Privacy operates across the authenticated organization; a workspace header does not narrow its effects.
- Approve the documented mutation and actual recipient/document targets before CLI --confirm or MCP confirm:true. A synthetic fixture authorizes no live agreement, notification or data deletion.
Discover the target
topolo whoami --json
topolo actions get app_topolo_sign.organizations.data.erase --detail --json
- Use the specifically approved organization context. Retain privacy exports securely.
Request
DELETE /api/organizations/data/erase
Inspect and test this action. Save the reviewed input as payload.json. Supply resource context separately.
Input fields
| Field | Required | Meaning | Constraints |
|---|---|---|---|
confirmation | Required | Literal ERASE after specific approval for organization-wide permanent data and signing-evidence erasure. | {"const":"ERASE"} |
Read the complete input schema.
Effects
- Permanently erases every Sign record for the organization: envelopes, recipients, templates, audit trails and stored signing documents.
- Completed envelopes and their audit certificates are erased too, so executed agreements lose the evidence of who signed and when.
Interpret the response
Read $.organization_id for the returned organization_erasure identifier. An empty collection does not discover a target.
Compare organization_id to the exact approved organization and inspect remaining core, envelope, audit and document_objects counters. Call organizations.data.export again in the same organization and verify every exported record collection is empty. Backup retention is reported separately and is not erased by this action.
Inspect the success schema. CLI/MCP add their transport envelope; --detail requests the full CLI result. HTTP 204 contains no JSON payload.
Worked examples
Captured from the exported Sign Worker with the existing SQLite-backed D1 harness applying all core, envelope and audit migrations to one local database, in-memory R2 and synthetic Auth/workspace/archive/Notify transports. These examples prove local validation, persistence and artifact production. They do not prove separate deployed D1 topology, real recipient consent, provider delivery or a live signed agreement. All identities, signing links and documents are synthetic; replace identifiers through authorized discovery and never execute a fixture against a live organization. Binary download examples use the released SDK binary projection; tests Base64-decode and compare original bytes, lengths and server SHA-256 headers.
Supported request · Erase local fixture records and stored document objects only
Input · payload.json:
{
"confirmation": "ERASE"
}
CLI:
topolo actions validate app_topolo_sign.organizations.data.erase --data @payload.json --json
topolo actions plan app_topolo_sign.organizations.data.erase --data @payload.json --json
topolo actions call app_topolo_sign.organizations.data.erase --data @payload.json --confirm --detail --json
MCP tool and arguments:
{
"tool": "topolo_call_action",
"arguments": {
"actionId": "app_topolo_sign.organizations.data.erase",
"input": {
"confirmation": "ERASE"
},
"confirm": true,
"detail": true
}
}
Captured exported Worker response · HTTP 200:
{
"success": true,
"organization_id": "org_acme",
"erased": true,
"remaining": {
"core": 0,
"envelope": 0,
"audit": 0,
"document_objects": 0
},
"backups_retained": true
}
HTTP 200. Compare organization_id to the exact approved organization and inspect remaining core, envelope, audit and document_objects counters. Call organizations.data.export again in the same organization and verify every exported record collection is empty. Backup retention is reported separately and is not erased by this action.
Refused request · HTTP 401
Input · payload.json:
{
"confirmation": "ERASE"
}
CLI:
topolo actions validate app_topolo_sign.organizations.data.erase --data @payload.json --json
topolo actions plan app_topolo_sign.organizations.data.erase --data @payload.json --json
Captured exported Worker response · HTTP 401:
{
"error": "Token validation failed"
}
HTTP 401. Resolve the exact refusal before retrying. This request is not a successful workflow.
Verify the result
- Compare organization_id to the exact approved organization and inspect remaining core, envelope, audit and document_objects counters.
- Call organizations.data.export again in the same organization and verify every exported record collection is empty. Backup retention is reported separately and is not erased by this action.
Errors and recovery
erase_confirmation_required(HTTP 400): Send confirmation exactly as the string "ERASE". This gate exists because the erasure cannot be undone.auth_error(HTTP 401): Reauthenticate in the same approved context before retrying.
Some existing refusals return a human message as error rather than a stable code; preserve the actual response, status and request id. Platform validation, authentication and resource checks can refuse before the handler.
Recovery boundary
There is no restore, and signature evidence is usually the thing an organization is least able to lose. Take organizations.data.export first and keep the payload before erasing anything.
Related actions
Evidence
Captured from the exported Sign Worker with the existing SQLite-backed D1 harness applying all core, envelope and audit migrations to one local database, in-memory R2 and synthetic Auth/workspace/archive/Notify transports. These examples prove local validation, persistence and artifact production. They do not prove separate deployed D1 topology, real recipient consent, provider delivery or a live signed agreement. All identities, signing links and documents are synthetic; replace identifiers through authorized discovery and never execute a fixture against a live organization. Binary download examples use the released SDK binary projection; tests Base64-decode and compare original bytes, lengths and server SHA-256 headers.