Skip to main content
This endpoint builds and executes a DELETE FROM … WHERE statement against the specified PostgreSQL table. The target row or rows are identified entirely through URL path parameters — no request body is required. The deleted record is returned via RETURNING *, giving the caller a final snapshot of the data that was removed.

Endpoint


Path Parameters

string
required
Name of the PostgreSQL table to delete from. Examples: customer, products.
string
required
Column name used in the WHERE clause to identify which row(s) to delete. Using a unique column such as id is strongly recommended to avoid unintended mass deletions.
string
required
The value that :property must equal for a row to be deleted. Interpolated into the SQL as a string literal: WHERE {property} = '{value}'.
The SQL executed against PostgreSQL is:

Request Body

None. All targeting information is supplied through the URL path.

Responses

200 — OK

Returned when at least one row was deleted (rowCount > 0).
number
Always 200 on success.
string
"Datos eliminados"
object
The first deleted row as returned by RETURNING *. If multiple rows were deleted, only rows[0] is included in the response — the rest are silently discarded.

404 — Not Found

Returned when rowCount === 0, meaning no rows matched the WHERE condition.

500 — Internal Server Error

Returned on any exception thrown by the pg driver (e.g., a foreign-key constraint prevents deletion, the table does not exist, or a connection error occurs).
object
Raw error from the pg driver. Check error.code (e.g., "23503" for a foreign-key violation) and error.detail for PostgreSQL-level diagnostics.

Examples

Example Response — DELETE /delete/customer/id/42


This deletes ALL rows that match the condition — not just one. The WHERE {property} = '{value}' clause has no LIMIT 1. If :property is not a unique column, every row whose value matches will be deleted permanently. Always use a unique identifier (such as id) as the :property parameter to avoid mass deletions. Additionally, the :value segment is interpolated directly into SQL — sanitize all inputs before exposing this endpoint in production to prevent SQL injection.