Topolo Docs Topolo Platform
Open workspace

Erase contact data

Permanently erase one contact's personal data from every Engage database (GDPR erasure). The contact, its email points, phone, WhatsApp consent evidence, list memberships and send reservations are deleted; active enrollments stop, scheduled messages are cancelled and every stored subject and body is cleared; reply threads close with subjects, snippets and bodies cleared; open tasks are cancelled and their text cleared. Only what honours the opt-out is kept: the suppression ledger keeps the salted address key (never the address) with an address-scoped erased event, so the same email is still refused if imported again. Cannot be undone; export first with contacts.export if needed. Audited with the reason only. 404 when the contact is not in this workspace or was already erased.

Outcome

Permanently erase one contact's personal data from every Engage database (GDPR erasure). The contact, its email points, phone, WhatsApp consent evidence, list memberships and send reservations are deleted; active enrollments stop, scheduled messages are cancelled and every stored subject and body is cleared; reply threads close with subjects, snippets and bodies cleared; open tasks are cancelled and their text cleared. Only what honours the opt-out is kept: the suppression ledger keeps the salted address key (never the address) with an address-scoped erased event, so the same email is still refused if imported again. Cannot be undone; export first with contacts.export if needed. Audited with the reason only. 404 when the contact is not in this workspace or was already erased.

Before you start

  • Verify the intended environment, signed-in credential, authorized organization and the action permission workspace:write.
  • Discover and select an authorized canonical Engage workspace. Pass resourceType=workspace and resourceId separately from action input.
  • Review the exact effects and obtain approval before CLI --confirm or MCP confirm:true. A local capture does not authorize a live mutation.

Discover the target

topolo whoami --json
topolo actions get app_topolo_engage.contacts.erase --json
topolo workspaces list topolo-engage --json

Set ENGAGE_WORKSPACE_ID to the identifier of the selected authorized workspace.

Input contract

FieldRequiredDeclared constraints
idYes{"type":"string","minLength":1,"maxLength":128}
reasonYes{"type":"string","enum":["data_subject_request","retention","other"]}

Validate, plan and execute

Build payload.json from the current schema and discovered identifiers. The action description above defines its behavior, limits, side effects and declared errors.

: "${ENGAGE_WORKSPACE_ID:?Set ENGAGE_WORKSPACE_ID to your selected workspace identifier}"
topolo actions validate app_topolo_engage.contacts.erase --data @payload.json --json
topolo actions plan app_topolo_engage.contacts.erase --resource-type workspace --resource-id "$ENGAGE_WORKSPACE_ID" --data @payload.json --confirm --json

Review the plan and approve its exact effects before executing the unchanged request.

: "${ENGAGE_WORKSPACE_ID:?Set ENGAGE_WORKSPACE_ID to your selected workspace identifier}"
topolo actions call app_topolo_engage.contacts.erase --resource-type workspace --resource-id "$ENGAGE_WORKSPACE_ID" --data @payload.json --confirm --json

For MCP, use topolo_get_action, topolo_validate_action, topolo_plan_action and topolo_call_action. Pass resource context separately where required; confirm:true is required for mutations.

Captured successful requests and responses

Captured HTTP 200 · contacts.erase > is gone after the first erase, needs write access and a listed reason

Action input

{
  "id": "contact_1",
  "reason": "data_subject_request"
}

Actual local response

{
  "erased": true,
  "enrollmentsStopped": 0,
  "tasksCancelled": 0,
  "threadsRedacted": 1
}

Source test: contacts.erase > is gone after the first erase, needs write access and a listed reason. Actual route handlers with SQLite repositories; synthetic identity/workspace grants and provider ports.

Captured HTTP 200 · contacts.erase > cancels open manual tasks and clears their text

Action input

{
  "id": "contact_1",
  "reason": "data_subject_request"
}

Actual local response

{
  "erased": true,
  "enrollmentsStopped": 0,
  "tasksCancelled": 1,
  "threadsRedacted": 0
}

Source test: contacts.erase > cancels open manual tasks and clears their text. Actual route handlers with SQLite repositories; synthetic identity/workspace grants and provider ports.

Captured HTTP 200 · contact phone and WhatsApp opt-in > erasure deletes the phone and consent evidence; the export includes them

Action input

{
  "id": "contact_1",
  "reason": "data_subject_request"
}

Actual local response

{
  "erased": true,
  "enrollmentsStopped": 0,
  "tasksCancelled": 0,
  "threadsRedacted": 0
}

Source test: contact phone and WhatsApp opt-in > erasure deletes the phone and consent evidence; the export includes them. Actual route handlers with SQLite repositories; synthetic identity/workspace grants and provider ports.

Effects and response meaning

  • Permanently erase one contact's personal data from every Engage database (GDPR erasure). The contact, its email points, phone, WhatsApp consent evidence, list memberships and send reservations are deleted; active enrollments stop, scheduled messages are cancelled and every stored subject and body is cleared; reply threads close with subjects, snippets and bodies cleared; open tasks are cancelled and their text cleared. Only what honours the opt-out is kept: the suppression ledger keeps the salted address key (never the address) with an address-scoped erased event, so the same email is still refused if imported again. Cannot be undone; export first with contacts.export if needed. Audited with the reason only. 404 when the contact is not in this workspace or was already erased.

Verify the outcome

  • Check the response against the declared output schema and the requested operation. For mutations, use the action-specific read described in the action description before any dependent operation.
  • For destructive results, verify the returned completion fields and stop; do not replay the request to confirm it.

Recover

For an uncertain result, inspect current retained state with a read action before retrying. Do not replay a mutation unless its contract explicitly guarantees idempotency.

Refused requests

Captured HTTP 403 · contacts.erase > is gone after the first erase, needs write access and a listed reason

Action input

{
  "id": "contact_1",
  "reason": "data_subject_request"
}

Actual local response

{
  "error": {
    "code": "permission_denied",
    "message": "The credential lacks workspace:write.",
    "details": {
      "requiredPermission": "workspace:write"
    }
  }
}

Source test: contacts.erase > is gone after the first erase, needs write access and a listed reason. Actual route handlers with SQLite repositories; synthetic identity/workspace grants and provider ports.

Captured HTTP 422 · contacts.erase > is gone after the first erase, needs write access and a listed reason

Refused input; do not execute

{
  "reason": "because ada@acme.io asked",
  "id": "contact_1"
}

Actual local response

{
  "error": {
    "code": "invalid_action_input",
    "message": "Input for contacts.erase is invalid.",
    "details": [
      {
        "code": "invalid_value",
        "values": [
          "data_subject_request",
          "retention",
          "other"
        ],
        "path": [
          "reason"
        ],
        "message": "Invalid option: expected one of \"data_subject_request\"|\"retention\"|\"other\""
      }
    ]
  }
}

Source test: contacts.erase > is gone after the first erase, needs write access and a listed reason. Actual route handlers with SQLite repositories; synthetic identity/workspace grants and provider ports.

Captured HTTP 404 · contacts.erase > is gone after the first erase, needs write access and a listed reason

Action input

{
  "id": "contact_1",
  "reason": "data_subject_request"
}

Actual local response

{
  "error": {
    "code": "not_found",
    "message": "Contact was not found."
  }
}

Source test: contacts.erase > is gone after the first erase, needs write access and a listed reason. Actual route handlers with SQLite repositories; synthetic identity/workspace grants and provider ports.

Error recovery

  • HTTP 403 permission_denied: Stop and inspect the current credential and selected resource. It needs workspace:write; do not broaden access or switch organization automatically.
  • HTTP 422 invalid_action_input: Correct the request against the current action input schema, then validate it again before planning.
  • HTTP 404 not_found: Rediscover the identifier using the related list or get action in the same authorized resource. Do not guess identifiers or change organization context.

Evidence and limits

  • /api/contacts/{id}/erase

  • Actual route handlers with SQLite repositories; synthetic identity/workspace grants and provider ports.

  • Widget/bootstrap use actual app handler but mocked worker runtime and app identity.

  • No gateway execution, live permissions, external delivery or deployed proof.

These are local route captures with synthetic identity and simulated dependencies. They do not prove live authorization, gateway execution, production state, or external delivery.