> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arcuserp.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Remove a purchase order line item
> Removes a line from a purchase order.
**Added 2026-08-17 (campaign PO-LINE-EDIT).** The internal application has
always had this verb; the public API had `POST /items` and
`PATCH /items/{itemId}` and no DELETE, so an API-key caller could add and
edit a line but could only "undo" an add by patching its quantity down.
Eligibility is stricter than for an edit, because a delete destroys the
line's identity rather than changing it:
- `draft`: allowed.
- `open`: allowed ONLY while the line has zero received units
(422 `line_has_receipts` otherwise -- reduce the quantity to what
arrived, or close the purchase order short).
- `processing`: never (422 `delete_blocked_on_processing`) -- the order
carries inventory layers and a three-way-match baseline.
- `fulfilled` / `cancelled` / `archived` / `expired`, or any status this
predicate has not ruled on: never.
- While awaiting approval: never.
A line with dependent records (receipts, vendor-bill lines, inventory
transactions, serials, allocations, backorders, returns, package items,
landed-cost attributions, or child lines) is refused with 422
`line_has_dependent_records` and the body names the blocking relations in
`blockers`. Previously such a delete surfaced as an unstructured 500.
Side effects (THE ONE RULE -- same canonical handler as the in-app
delete), all inside one transaction: unlinks any sales-order lines that
were drop-shipping this exact product through this purchase order,
decrements the `on_purchase_order` cache by the unreceived quantity,
recomputes the purchase-order header total, bumps `revision_count` on a
sent order, and emits Rule 13 broadcasts plus a `po_item_removed` (or
`po_revised`) activity entry.
Required API key scope: `purchasing:write`
## OpenAPI
````yaml /openapi.yaml delete /purchase-orders/{id}/items/{itemId}
openapi: 3.1.0
info:
title: Arcus ERP Public API
version: 1.0.0
description: >
Arcus ERP public REST API. Designed for external integrations and data
migration.
**Authentication.** Bearer token (API key) via the `Authorization` header.
Format: `Authorization: Bearer ark_live_ent__` (or
`ark_test_*` for sandbox).
API keys are issued per-entity in **Settings > Developers > API Keys**.
**Entity scoping.** The entity is encoded in the API key prefix; routes are
flat
(e.g. `/v1/accounts`, `/v1/orders`, `/v1/products`). A small set of platform
endpoints
(migration, reconciliation, events, webhook endpoints, API keys) use the
`/v1/entities/{entity_id}/...` form -- those are noted in their tags.
**Key capabilities.**
- Related-resource hydration via `?expand[]=` (see `x-arcus-expand` on each resource).
- Cursor-based pagination (`starting_after` / `ending_before` / `limit`).
- Idempotency via the `Idempotency-Key` header.
- Webhook events for asynchronous notification.
- Conditional requests / ETag for cache validation.
servers:
- url: https://api.arcuserp.com/v1
description: Arcus ERP API (accepts both live `ark_live_*` and test `ark_test_*` keys)
- url: https://dev-api.arcuserp.com/v1
description: >-
Dev sandbox API (test-only data, accepts `ark_test_*` keys against dev
RDS)
security: []
paths:
/purchase-orders/{id}/items/{itemId}:
parameters:
- name: id
in: path
required: true
schema:
type: string
format: uuid
description: The purchase order id.
- name: itemId
in: path
required: true
schema:
type: string
format: uuid
description: The PO line item (order_item) id to edit.
delete:
tags:
- Purchasing
summary: Remove a purchase order line item
description: >
Removes a line from a purchase order.
**Added 2026-08-17 (campaign PO-LINE-EDIT).** The internal application
has
always had this verb; the public API had `POST /items` and
`PATCH /items/{itemId}` and no DELETE, so an API-key caller could add
and
edit a line but could only "undo" an add by patching its quantity down.
Eligibility is stricter than for an edit, because a delete destroys the
line's identity rather than changing it:
- `draft`: allowed.
- `open`: allowed ONLY while the line has zero received units
(422 `line_has_receipts` otherwise -- reduce the quantity to what
arrived, or close the purchase order short).
- `processing`: never (422 `delete_blocked_on_processing`) -- the order
carries inventory layers and a three-way-match baseline.
- `fulfilled` / `cancelled` / `archived` / `expired`, or any status this
predicate has not ruled on: never.
- While awaiting approval: never.
A line with dependent records (receipts, vendor-bill lines, inventory
transactions, serials, allocations, backorders, returns, package items,
landed-cost attributions, or child lines) is refused with 422
`line_has_dependent_records` and the body names the blocking relations
in
`blockers`. Previously such a delete surfaced as an unstructured 500.
Side effects (THE ONE RULE -- same canonical handler as the in-app
delete), all inside one transaction: unlinks any sales-order lines that
were drop-shipping this exact product through this purchase order,
decrements the `on_purchase_order` cache by the unreceived quantity,
recomputes the purchase-order header total, bumps `revision_count` on a
sent order, and emits Rule 13 broadcasts plus a `po_item_removed` (or
`po_revised`) activity entry.
Required API key scope: `purchasing:write`
operationId: deletePurchaseOrderItemV1
parameters:
- name: Idempotency-Key
in: header
required: false
schema:
type: string
maxLength: 255
description: Optional idempotency key for safe retries (Stripe-style).
responses:
'200':
description: >
Line removed. `unlinked_dropship_order_ids` lists any sales orders
whose
drop-ship link to this purchase order was cleared as a result (empty
on
every non-drop-ship delete).
content:
application/json:
schema:
type: object
properties:
deleted:
type: boolean
id:
type: string
format: uuid
unlinked_dropship_order_ids:
type: array
items:
type: string
format: uuid
'400':
$ref: '#/components/responses/Error'
'401':
$ref: '#/components/responses/Error'
'403':
$ref: '#/components/responses/Error'
'404':
$ref: '#/components/responses/Error'
'422':
description: |
Delete refused. One of: `po_pending_approval_edit_locked`,
`po_pending_approval_and_terminal`, `po_status_locked`,
`po_status_unknown_locked`, `notes_only_on_terminal`,
`line_has_receipts`, `delete_blocked_on_processing`, or
`line_has_dependent_records` (body carries `blockers`).
content:
application/json:
schema:
$ref: '#/components/responses/Error'
security:
- ApiKeyAuth: []
components:
responses:
Error:
description: Error response (400/401/403/404/409/422/429/500)
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorEnvelope'
schemas:
ErrorEnvelope:
type: object
description: |
Canonical error response envelope. All API errors use this shape.
required:
- error
- code
properties:
error:
type: string
description: Machine-readable error key
example: not_found
code:
type: string
description: Machine-readable error code (often same as error)
example: not_found
type:
type: string
enum:
- validation_error
- permission_error
- not_found
- conflict
- rate_limit
- internal
- expand_error
- not_implemented
example: not_found
hint:
type: string
description: Human-readable one-sentence explanation (English)
example: >-
The requested order does not exist or does not belong to this
entity.
param:
type: string
description: The parameter that caused the error, if applicable
example: expand[0]
required:
type: string
description: The scope required (only on insufficient_scope errors)
example: accounts:read
request_id:
type: string
description: >-
Unique request ID for support tracing (maps to CloudWatch log
stream)
example: req_abc123
securitySchemes:
ApiKeyAuth:
type: http
scheme: bearer
description: |
API key issued per entity via Settings > Developers > API Keys.
Each key carries scopes (e.g. orders:read, products:write).
Bearer token format: Authorization: Bearer ark_live_ent__
Test keys use ark_test_ent__. Both are issued per entity
via Settings > Developers > API Keys.
````