curl -X DELETE "$base_url/public/v1/teardowns/$teardown_id" \
-H "Authorization: Bearer $api_key" \
-H "X-Organization-Id: $org_id"
import requests
resp = requests.delete(
f"{base_url}/public/v1/teardowns/{teardown_id}",
headers={
"Authorization": f"Bearer {api_key}",
"X-Organization-Id": org_id,
},
)
if resp.status_code == 204:
print("Deleted")
elif resp.status_code == 404:
print("Not found (or not yours)")
else:
resp.raise_for_status()
HTTP/1.1 204 No Content
{
"detail": "Teardown not found"
}
Teardowns
Delete a teardown
Hard delete removes the row + storage files.
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"
import requests
resp = requests.delete(
f"{base_url}/public/v1/teardowns/{teardown_id}",
headers={
"Authorization": f"Bearer {api_key}",
"X-Organization-Id": org_id,
},
)
if resp.status_code == 204:
print("Deleted")
elif resp.status_code == 404:
print("Not found (or not yours)")
else:
resp.raise_for_status()
HTTP/1.1 204 No Content
{
"detail": "Teardown not found"
}
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.
The teardown’s
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
string
required
Bearer tdao_live_…string
required
Your organization’s UUID.
Path parameters
string (UUID)
required
Auth requirements
Requires theseller 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
- The teardown row is fetched and ownership checked. If it doesn’t belong to your org, 404.
- A
teardown.deletedaudit row is written with key fields snapshotted inprevious_state(tail_number, msn, status, label, start_date, country). Theentity_idkeeps pointing at the deleted teardown’s UUID audit logs outlive the entity. - 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. - The teardown row is hard-deleted from the database in the same transaction as the audit write.
204 No Contentis returned with an empty body.
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"
import requests
resp = requests.delete(
f"{base_url}/public/v1/teardowns/{teardown_id}",
headers={
"Authorization": f"Bearer {api_key}",
"X-Organization-Id": org_id,
},
)
if resp.status_code == 204:
print("Deleted")
elif resp.status_code == 404:
print("Not found (or not yours)")
else:
resp.raise_for_status()
HTTP/1.1 204 No Content
{
"detail": "Teardown not found"
}
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"}'
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 returns404 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
- Transition for soft deletes.
- Errors for
404semantics.