Teardowns
Transition a teardown
Move a teardown through the lifecycle state machine.
POST
Drives a teardown between lifecycle states. Use this not PATCH to
change a teardown’s
status. Each action is validated against the
state machine; trying an invalid transition returns 400 with a clear
message.
See status lifecycle for the full state
diagram.
Headers
string
required
Bearer tdao_live_…string
required
Your organization’s UUID.
string
required
application/jsonPath parameters
string (UUID)
required
Body
string
required
The transition action to perform. See the table below.
string
Required when
action="reject". Optional otherwise. Stored in the
audit row’s metadata.Actions
Response
200 OK. A small transition response:
string (UUID)
The teardown’s id.
string
The new status after the transition.
string | null
The prior status. Populated for admin-only transitions; usually
null for the seller-facing actions listed above.The transition endpoint currently returns the internal field names
(
id, status). The other teardown endpoints have moved to the
partner-facing names (teardown_id, etc.). We’ll align this in a
future release.Audit trail
Every transition writes one audit row:action=teardown.<your-action>(e.g.,teardown.complete,teardown.archive).previous_state={ "status": "<old-status>" }new_state={ "status": "<new-status>" }metadata.via_api = trueplus the standard API-key tags.- For
reject:metadata.reasoncarries your reason string.
See also
- Status lifecycle for the full state diagram and the conceptual model.
- Delete a teardown for hard delete vs. archive trade-offs.
- Update a teardown for changing
fields other than
status.

