Skip to main content
On this page

Soft delete & rollback

Every automation carries an operational concern: what happens if an agent or integration deletes the wrong records? On etg24, the answer is an instant, self-service recovery workflow rather than a catastrophic database restore from offline backups.

Soft delete mechanics

When an API call or MCP tool deletes a contact, unit, or document on etg24, the record is not permanently destroyed. Instead, the platform applies a soft delete:

  • The record remains securely stored in the PostgreSQL database.
  • A deletedAt timestamp and deletion flag are set.
  • All relationships and foreign key integrity are preserved.

In JSON representations, a soft-deleted record appears with explicit status flags:

{
  "id": "cnt_456789ab-cdef-0123-4567-89abcdef0123",
  "firstName": "Max",
  "lastName": "Mustermann",
  "deletedAt": "2026-03-24T11:15:00.000Z",
  "isDeleted": true
}

By default, standard query endpoints automatically filter out soft-deleted records. Normal day-to-day operations and active searches will not display them, preventing operational confusion.

Incident response runbook: Reversing agent mistakes

If an automated process or an LLM agent executes unintended deletions, follow this structured four-step recovery workflow:

Step 1: Pinpoint the incident in the audit trail

Inspect the audit trail to identify:

  • Which agent initiated the deletion
  • The exact entity IDs affected
  • The precise timestamp of the incident

Step 2: Emergency containment

Immediately disable the agent’s API key in your portal settings. Key revocation takes effect across all distributed nodes within seconds, preventing any further unintended writes while you assess the situation.

Step 3: Execute the rollback command

Because data is soft-deleted, recovery does not require restoring raw database snapshots or risking data loss from subsequent valid transactions. Instead, call the corresponding restore command:

Terminal window
curl -s -X POST "https://api.etg24.de/propertymanagement/v2/command/contacts.restore" \
  -H "Authorization: Bearer ADMIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"id": "cnt_456789ab-cdef-0123-4567-89abcdef0123"}'

The restore operation clears the deletedAt marker, returning the record to active status instantly and recording an attributable restore event in the audit trail.

Step 4: Validate and re-enable

Once data integrity is verified, adjust your agent’s prompts or code logic, generate a new scoped key if needed, and resume operations.

Blast radius containment with permission scopes

Soft delete works in combination with strict permission scopes:

  • Standard write keys (capable of creating and updating records) cannot delete records unless the explicit delete scope is granted.
  • Routine automations (like email drafting or note logging) should never carry destructive permissions.
  • Even if a credential with delete permissions is compromised or malfunctions, the blast radius is strictly contained because every deletion remains fully reversible.