Skip to main content

Trash and restore

Removal is two-stage on purpose. Trashing is reversible and available to the people doing the work; permanent deletion is narrow and administrative.

Trash​

curl -s -X PATCH "$BASE/warrants/$WARRANT_ID/trash" \
  -H "x-api-key: $API_KEY" \
  -H "X-On-Behalf-Of: dr.chen@example.gov"

The application keeps its state and its warrant_number, gains a deleted_at timestamp, and drops out of the ordinary lists. Only the applicant or an administrator can trash an application.

List the trash​

curl -s "$BASE/warrants?trashed_only=true" -H "x-api-key: $API_KEY"

Restore​

curl -s -X PATCH "$BASE/warrants/$WARRANT_ID/restore" \
  -H "x-api-key: $API_KEY" \
  -H "X-On-Behalf-Of: dr.chen@example.gov"

The application returns to the state it was in, with its comments, attachments, and history intact. Trashing and restoring never change the workflow state: a trashed SIGNED warrant restores as SIGNED.

Permanent deletion​

curl -s -X DELETE "$BASE/warrants/$WARRANT_ID" \
  -H "x-api-key: $API_KEY" \
  -H "X-On-Behalf-Of: admin.reyes@example.gov"

Deletion is administrative and deliberately narrow. It applies to:

  • any trashed application, or
  • an untrashed application still in DRAFT.

An active SUBMITTED, SIGNED, or REJECTED application cannot be deleted outright. Trash it first, which is a decision someone has to make explicitly and which is recorded.

Deletion removes the application and its attachments. What survives is the audit trail: the record that the application existed, who worked it, and who deleted it. That is the point of an audit trail, and it is why deletion is not a way to make a warrant unhappen.

Check your jurisdiction's retention rules before wiring automated deletion into anything. A signed warrant is usually a court record with a statutory retention period, and this API will happily do what you tell it.