Skip to main content
DELETE
/
public
/
v1
/
teardowns
/
{teardown_id}
curl -X DELETE "$base_url/public/v1/teardowns/$teardown_id" \
  -H "Authorization: Bearer $api_key" \
  -H "X-Organization-Id: $org_id"

HTTP/1.1 204 No Content

Documentation Index

Fetch the complete documentation index at: https://teardowns.aero/docs/llms.txt

Use this file to discover all available pages before exploring further.

Permanently removes a teardown owned by your organization. The teardown row is hard-deleted from the database; every attached file is best-effort deleted from Supabase Storage.
This is irreversible. The row is gone, and storage files are scheduled for deletion. If you want a recoverable “delete”, use the transition endpoint with action="archive" instead the teardown drops out of the active feed but the data stays intact.

​
Headers

​
Authorization
string
required
Bearer tdao_live_…
​
X-Organization-Id
string
required
Your organization’s UUID.

​
Path parameters

​
teardown_id
string (UUID)
required

​
Auth requirements

Requires the seller capability on the user who minted the key (same gate as create / update). Cross-org access returns 404 not_found never reveals existence in another org.

​
What happens, in order

  1. The teardown row is fetched and ownership checked. If it doesn’t belong to your org, 404.
  2. A teardown.deleted audit row is written with key fields snapshotted in previous_state (tail_number, msn, status, label, start_date, country). The entity_id keeps pointing at the deleted teardown’s UUID audit logs outlive the entity.
  3. Every URL in documents[], images[], and the four slot fields (harvest_list, occm, aircraft_details_doc, non_incident_statement) is parsed back to its Supabase Storage path and deleted. Individual file failures are logged but never fail the call storage orphans are recoverable; a failed delete is not.
  4. The teardown row is hard-deleted from the database in the same transaction as the audit write.
  5. 204 No Content is returned with an empty body.
No other table foreign-keys back to teardowns (verified across migrations 001-023), so there are no cascading dependents to clean up.

​
Response

204 No Content. Empty body. 
curl -X DELETE "$base_url/public/v1/teardowns/$teardown_id" \
  -H "Authorization: Bearer $api_key" \
  -H "X-Organization-Id: $org_id"

HTTP/1.1 204 No Content

​
Soft delete (recoverable alternative)

If you want the teardown to disappear from browse / search but keep the data and the row for compliance / restoration: 
curl -X POST "$base_url/public/v1/teardowns/transition/$teardown_id" \
  -H "Authorization: Bearer $api_key" \
  -H "X-Organization-Id: $org_id" \
  -H "Content-Type: application/json" \
  -d '{"action": "archive"}'
The teardown’s status becomes archived, it drops out of browse results, but the row, attachments, and audit history all stay intact. A subsequent {"action":"restore"} transition puts it back as a draft.

​
Idempotency

DELETE is not idempotent in the strict HTTP sense: the second call returns 404 Teardown not found because the row is gone after the first call. If your ERP needs idempotent semantics, treat both 204 and 404 as “effectively deleted” the end-state is the same.

​
See also