Erase Inventory organization data

Outcome

With exact ERASE confirmation, refuse pending movement reviews or processing imports, then delete all six local Inventory stores across the organization and verify zero residual rows. Auth identity and other-owner data remain.

Before you start

• Verify the authenticated identity, exact environment and pinned approved organization context before preparing an action.
• The published application permission is privacy:write. This is organization-wide and is not restricted by a workspace header; obtain the specific privacy purpose and authorization.
• Authorize the documented inventory, review, import, notification, metering, privacy or archival effects before CLI --confirm or MCP confirm:true.

Discover the target

topolo whoami --json
topolo actions get app_topolo_inventory.organizations.data.erase --detail --json

• Use the exact authenticated organization id. A workspace resource header does not narrow this action.

Request

DELETE /api/organizations/{organizationId}/data

Save action input as payload.json. Inspect the plan for the exact path, query and body.

Inspect and test this action in the signed action console, then perform the verification below.

Input fields

View the complete input schema in the action console. The same schema is available through CLI and MCP action discovery.

Effects

• Before deletion counts pending reviews and processing imports; any nonzero count returns 409 with both blocker counts.
• Records initial counts, deletes movements D1 first, then executes a core D1 batch for imports, settings, items, locations and local mirrors. The two databases are not one atomic transaction; later failure can leave partial deletion.
• Verifies six remaining counts. deleted is the pre-delete snapshot, not per-statement affected-row receipt; verified zero is the scoped local post-delete read.
• Preserves platform Auth identity/workspaces, delivered Notify data and backup copies governed elsewhere. No durable write prohibition is established; later authorized Inventory writes can recreate local rows.

Interpret the response

Use response path $.organizationId for organization. An empty list does not discover a target.

Expect ok true, intended organizationId, erasedAt and all six verified values zero. Call organizations.data.export for the same authorized organization to verify empty local arrays. Do not claim Auth, notifications, backups or concurrent future writes were erased.

The success schema was checked against captured handler responses. Delegated Auth profile and canonical widget context fields can vary; exact Inventory projections and all six raw SQL export stores are source-reviewed. Error examples retain their actual refusal shapes.

View the complete success schema in the action console. The worked examples below retain complete captured responses; action discovery supplies the exact schema.

Worked examples

Captured exported Worker responses use both real local SQLite D1 databases with all six committed migrations, synthetic Auth/workspace grants and simulated Notify/Nexus/archive transport. They prove local handler shapes and scoped behavior, not live authorization, notification delivery, metering acceptance or environment deployment. Large 100-row list/capped-dashboard captures are retained in local evidence; committed tests verify those limits while worked guides use smaller complete responses. Refused examples demonstrate boundaries and must not be executed as successful workflows.

Successful request

Actual exported Worker response with both local SQLite D1 databases and all committed migrations; synthetic Auth/grants and simulated Notify/Nexus/archive transport. No live delivery, billing or environment deployment proof. Captured scenario: organizations.data.erase.

Input · payload.json:

{
  "organizationId": "org_inventory_fixture",
  "confirmation": "ERASE"
}

CLI:

topolo actions validate app_topolo_inventory.organizations.data.erase --data @payload.json --json
topolo actions plan app_topolo_inventory.organizations.data.erase --data @payload.json --json
topolo actions call app_topolo_inventory.organizations.data.erase --data @payload.json --confirm --json

MCP tool and arguments:

{
  "tool": "topolo_call_action",
  "arguments": {
    "actionId": "app_topolo_inventory.organizations.data.erase",
    "input": {
      "organizationId": "org_inventory_fixture",
      "confirmation": "ERASE"
    },
    "confirm": true
  }
}

Captured local response · HTTP 200:

{
  "ok": true,
  "organizationId": "org_inventory_fixture",
  "erasedAt": "2026-10-04T05:46:38.316Z",
  "deleted": {
    "inventory_stock_movements": 1,
    "inventory_workspaces": 2,
    "inventory_items": 1,
    "inventory_locations": 1,
    "inventory_import_jobs": 1,
    "inventory_workspace_settings": 1
  },
  "verified": {
    "inventory_stock_movements": 0,
    "inventory_workspaces": 0,
    "inventory_items": 0,
    "inventory_locations": 0,
    "inventory_import_jobs": 0,
    "inventory_workspace_settings": 0
  }
}

HTTP 200. Expect ok true, intended organizationId, erasedAt and all six verified values zero. Call organizations.data.export for the same authorized organization to verify empty local arrays. Do not claim Auth, notifications, backups or concurrent future writes were erased.

Refused request · HTTP 400

Actual exported Worker response with both local SQLite D1 databases and all committed migrations; synthetic Auth/grants and simulated Notify/Nexus/archive transport. No live delivery, billing or environment deployment proof. Captured scenario: exact ERASE required.

Input · payload.json:

{
  "organizationId": "org_inventory_fixture",
  "confirmation": "erase"
}

CLI:

topolo actions validate app_topolo_inventory.organizations.data.erase --data @payload.json --json
topolo actions plan app_topolo_inventory.organizations.data.erase --data @payload.json --json

Captured local response · HTTP 400:

{
  "success": false,
  "error": {
    "code": "invalid_action_input",
    "message": "Invalid action input for \"organizations.data.erase\".",
    "action": "organizations.data.erase",
    "issues": [
      {
        "path": "confirmation",
        "message": "Invalid input: expected \"ERASE\"",
        "code": "invalid_value"
      }
    ]
  }
}

HTTP 400. The handler refused this request. Resolve its exact cause before retrying; input validation can reject an invalid fixture before it reaches the handler.

Refused request · HTTP 409

Actual exported Worker response with both local SQLite D1 databases and all committed migrations; synthetic Auth/grants and simulated Notify/Nexus/archive transport. No live delivery, billing or environment deployment proof. Captured scenario: pending review prevents erasure.

Input · payload.json:

{
  "organizationId": "org_inventory_fixture",
  "confirmation": "ERASE"
}

CLI:

topolo actions validate app_topolo_inventory.organizations.data.erase --data @payload.json --json
topolo actions plan app_topolo_inventory.organizations.data.erase --data @payload.json --json

Captured local response · HTTP 409:

{
  "ok": false,
  "status": 409,
  "error": "organization_data_erasure_blocked",
  "blockers": {
    "pendingMovementReviews": 1,
    "runningImports": 0
  }
}

HTTP 409. The handler refused this request. Resolve its exact cause before retrying; input validation can reject an invalid fixture before it reaches the handler.

Refused request · HTTP 409

Actual exported Worker response with both local SQLite D1 databases and all committed migrations; synthetic Auth/grants and simulated Notify/Nexus/archive transport. No live delivery, billing or environment deployment proof. Captured scenario: processing import prevents erasure.

Input · payload.json:

{
  "organizationId": "org_inventory_fixture",
  "confirmation": "ERASE"
}

CLI:

topolo actions validate app_topolo_inventory.organizations.data.erase --data @payload.json --json
topolo actions plan app_topolo_inventory.organizations.data.erase --data @payload.json --json

Captured local response · HTTP 409:

{
  "ok": false,
  "status": 409,
  "error": "organization_data_erasure_blocked",
  "blockers": {
    "pendingMovementReviews": 0,
    "runningImports": 1
  }
}

HTTP 409. The handler refused this request. Resolve its exact cause before retrying; input validation can reject an invalid fixture before it reaches the handler.

Verify the result

• Expect ok true, intended organizationId, erasedAt and all six verified values zero.
• Call organizations.data.export for the same authorized organization to verify empty local arrays. Do not claim Auth, notifications, backups or concurrent future writes were erased.

Errors and recovery

• invalid_action_input (HTTP 400): Correct only the exact fields reported by the published schema validator. An invalid input can be refused before its handler.
• action_permission_required (HTTP 403): Stop when the verified credential lacks the published action permission. Resource identifiers and organization ownership do not grant that permission.
• organization_forbidden (HTTP 403): Use the exact authenticated organization id.
• confirmation_required (HTTP 400): The handler requires exactly ERASE; published action validation usually returns invalid_action_input first for a different value.
• organization_data_erasure_blocked (HTTP 409): Inspect pendingMovementReviews and runningImports. Resolve pending reviews only on their merits; no published import cancellation action exists. Do not fabricate approval or clear processing rows via another endpoint.
• organization_data_erasure_incomplete (HTTP 500): Inspect remaining counts and scoped export after partial deletion. No automatic rollback or cross-database atomicity is promised.

Auth, action-input validation and platform resource resolution can refuse a request before its handler. Retain the exact error, request id and context; requesting another context is not a legitimate way to bypass a refusal.

Recovery boundary

Local erasure is irreversible through the published action surface. Export beforehand when authorized, resolve blockers deliberately, and inspect all six stores after ambiguous or partial failure. Replaying requires renewed authorization for the exact destructive scope.

Related actions

• Export Inventory organization data: Export all six local Inventory stores across every workspace of the authenticated organization, with raw SQL column names. A workspace header does not narrow the scope and free-text/customer fields are not redacted.

Evidence

Captured exported Worker responses use both real local SQLite D1 databases with all six committed migrations, synthetic Auth/workspace grants and simulated Notify/Nexus/archive transport. They prove local handler shapes and scoped behavior, not live authorization, notification delivery, metering acceptance or environment deployment. Large 100-row list/capped-dashboard captures are retained in local evidence; committed tests verify those limits while worked guides use smaller complete responses. Capture digests and test scenarios are retained in the source fixture records.