Deleting

Summary

When the user presses Ctrl+D and confirms deletion, the client sends a DeleteRequest. Your server deletes the record and returns a list.

What the client sends

Route

The client POSTs to the URL from actions.delete on the current ScreenContract.

POST /screen/customer_card/10000/delete

DeleteRequest

{
  "screen_id": "customer_card",
  "record_id": "10000"
}

Property	Type	Purpose
screen_id	string	Echoed from ScreenContract.screen_id — the stable machine identifier you set on the screen
record_id	string	Record identifier

The URL path is authoritative. Your server should identify the record from the URL, not the body. The body fields are informational (for logging or audit).

What to return

Success

Return HTTP 200 with a List ScreenContract — the record is gone, so the card is no longer valid:

{
  "layout": "List",
  "title": "Customers",
  "status": "Deleted.",
  "lines": {
    "columns": [],
    "rows": [],
    "selectable": true,
    "on_select": "/screen/customer_card/{0}"
  }
}

The client replaces the current screen with the list. The status field shows "Deleted." in the bottom bar.

Errors

For business logic errors (record has dependent data, user lacks permission), return HTTP 200 with the error in status and the card still displayed:

{
  "layout": "Card",
  "title": "Customer Card - 10000",
  "status": "Cannot delete: Customer has open ledger entries.",
  "sections": []
}

For infrastructure errors, return the appropriate HTTP status code with an ErrorResponse body.

Confirmation

The client shows a confirmation dialog before sending the delete request. The server does not need to handle confirmation — it only receives the request if the user confirmed.

Omitting delete

If a record cannot be deleted, omit delete from the actions map. The client will not show the delete shortcut for that screen.