---
title: "Delete Paddock"
method: DELETE
path: "/paddocks/{id}"
tags: ["Paddocks"]
---

# Delete Paddock

`DELETE /paddocks/{id}`

## Request

- Base URL: `https://api.purplegrain.com/api/v1`
- URL: `https://api.purplegrain.com/api/v1/paddocks/{id}`
- Auth: HTTP bearer

Removes the paddock for good — and only while nothing is filed on it.

**A paddock with any record or open task cannot be removed: the request
is refused with a `409`** whose `errors[0].detail` names the counts
("North Block has 3 records and 1 open task on it — archive this paddock
instead of removing it") and whose `errors[0].code` is `asset_in_use`.
The counts are read inside the delete's own transaction, not from the
numbers a client read earlier, so a paddock that acquired history
between a client's check and its `DELETE` is kept rather than silently
unfiled. Archive it instead (`PUT { archived: true }`): its records stay
on the property, and the paddock stays openable from the archive drawer.

A client offers "Remove this paddock" only while `record_count` and
`open_task_count` are both zero and "Archive this paddock" otherwise —
and treats a `409` as the archive face, because the numbers moved under
it. The movement pointers on other assets' records (`from_paddock_id` /
`to_paddock_id`) are nullified when an empty paddock is removed, so no
mob is left pinned to a paddock that no longer exists.

## Path parameters

- `id` string, required

## Response `204`

Deleted

## Other responses

- `401`: Unauthorized
- `403`: Forbidden
- `404`: Not Found
- `409`: Conflict — the paddock has records or open tasks on it, so it can be archived but not removed. `errors[0].detail` names both counts and says to archive instead; `errors[0].code` is `asset_in_use`. Nothing was changed.

---

[API](https://skmtc.dev/purplegrain/apis/purple-grain-api.md) · [All operations](https://skmtc.dev/purplegrain/apis/purple-grain-api/llms.txt) · [OpenAPI document](https://skmtc.dev/purplegrain/apis/purple-grain-api/revisions/a9136f78e9fb?raw)