Repairs
Hold and disposition stock with compatibility types, sentinel dates, and complete/release actions.
Repairs API
A repair holds stock out of availability until it is dispositioned. It can hold a loose quantity or a specific barcoded asset, and is completed by returning stock to inventory, writing it off, or a mix of both across partial dispositions. An active repair writes a positive demand into the Availability Engine, so held stock consumes a unit exactly like a booking; the demand voids automatically when the repair completes or its window passes.
The API is compatibility aliases: repair_type is emitted as an integer, open-ended repairs carry a sentinel ends_at of 2999-12-31T23:59:59.999Z, and the index defaults to active repairs only.
Endpoints
| Method | URL | Description |
|---|---|---|
| GET | /api/v1/repairs |
List repairs (active only by default) |
| POST | /api/v1/repairs |
Raise a repair |
| GET | /api/v1/repairs/{repair} |
Show a repair with its transactions |
| PUT/PATCH | /api/v1/repairs/{repair} |
Update repair metadata |
| DELETE | /api/v1/repairs/{repair} |
Cancel an active repair |
| POST | /api/v1/repairs/{repair}/complete |
Complete with typed dispositions |
| POST | /api/v1/repairs/{repair}/release |
Release held stock back to inventory |
Authentication
Requires repairs:read (GET) or repairs:write (POST/PUT/PATCH/DELETE) with repairs.view, repairs.create, and repairs.release permissions as applicable. Access is warehouse-scoped through RepairPolicy.
List repairs
GET /api/v1/repairs
Defaults to repairs whose status phase is active. Pass ?filtermode=all to include completed and cancelled records. Ransack filters cover reason, status, asset, warehouse, and timestamps.
Raise a repair
POST /api/v1/repairs
Holds either a loose quantity or a barcoded asset. Barcoded conflict handling at raise time:
| Asset state | Behaviour |
|---|---|
| Free | Repairs cleanly |
| Future confirmed allocation | Displaced (requires the displacement permission); the affected order surfaces as short |
| Currently dispatched | Rejected — route the asset through the return/check-in flow first |
Complete
POST /api/v1/repairs/{repair}/complete
Accepts typed dispositions (1 Return to Stock, 2 Write Off), which may be mixed and partial across the held quantity. A barcoded write-off retires the asset through the shared retirement path. A write-off reduces held stock and voids the repair demand in the same step, so availability is never double-counted.
Cancel
DELETE cancels an active repair (status phase → cancelled) and returns 204.
Response shape
RepairData flattens the held item to item_id/name, emits an integer repair_type, a sentinel ends_at when open-ended, and a read-only active flag. Child dispositions serialise through RepairTransactionData. Damage-photo attachments are supported via the polymorphic attachments surface.
Webhooks
repair.created, repair.updated, repair.released — see Webhooks.