Approve a purchase order

Approves a draft purchase order, transitioning it to status: approved. Approved POs increment the quantity-on-order count for each line item’s product-location pair. Requires purchasing:write scope.

This endpoint does NOT email the vendor. Sending the purchase order to the vendor is a separate, explicit verb (POST /purchase-orders/{id}/send), which is also the only place the sent_at stamp is written. (Corrected 2026-08-17: this description previously said an approval email is “optionally sent to the vendor when notify_vendor: true is specified”. approvePurchaseOrder has never read a notify_vendor field — the only handler in routes/purchasing.mjs that reads one is cancelPurchaseOrder. The sentence was authored by the 2026-05-12 description backfill and had no implementation behind it at any point.)

Re-approving a stale approval (reapprove_stale, 2026-08-17). When a line edit raises a purchase order’s total ABOVE the total that was approved, the order stays approved and non-blocking (receiving, billing and every other action keep working) while GET /purchase-orders/{id} reports approval_stale: true alongside the approved_total snapshot. Send reapprove_stale: true to record a fresh approval at the current amount.

This is an explicit opt-in, and WITHOUT it the endpoint’s behaviour is unchanged: a purchase order that is not pending still returns 400. WITH it, the endpoint accepts ONLY a genuinely stale order and refuses everything else with a structured 422: po_not_approved (the order is not approved), approval_basis_missing (approved before approval totals were recorded, so there is no basis to refresh), or approval_not_stale (the total does not exceed the approved amount — also what a duplicate request receives, since the check is re-evaluated under a row lock).

A re-approval re-stamps the approver, the timestamp and the approved total. It does NOT move the order back to pending (that would stop receiving) and does NOT re-run the status transition (an order already in processing stays there). Separation of duties, the purchasing:approve scope and the high-value approval band are all enforced exactly as they are on a first approval — and the band is re-evaluated against the NEW total, which may have crossed a threshold the original approval did not.

POST /purchase-orders/{id}/approve

Approve a purchase order

cURL

curl --request POST \
  --url https://api.arcuserp.com/v1/purchase-orders/{id}/approve \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --data '
{
  "notes": "<string>",
  "reapprove_stale": true
}
'

200

{
  "id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
  "object": "purchase_order",
  "entity_id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
  "po_number": "<string>",
  "vendor_id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
  "location_id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
  "status": "draft",
  "po_date": "2023-11-07T05:31:56Z",
  "expected_date": "2023-11-07T05:31:56Z",
  "subtotal": 123,
  "tax_total": 123,
  "shipping_total": 123,
  "po_total": 123,
  "currency": "USD",
  "notes": "<string>",
  "internal_notes": "<string>",
  "metadata": {},
  "created_at": "2023-11-07T05:31:56Z",
  "updated_at": "2023-11-07T05:31:56Z",
  "approved_total": 123,
  "approval_stale": true,
  "header_editability": {},
  "billed_total": 123,
  "unbilled_balance": 123
}

Authorizations

Authorization · string · header · required

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.

Path Parameters

id · string<uuid> · required

Body

application/json

notes · string

Approval notes recorded on the purchase order.

reapprove_stale · boolean

Record a fresh approval at the current total on an already-approved purchase order whose total has risen above its approved amount (approval_stale: true). Refused with 422 on any other order state.

Response

200

application/json

Approved purchase order

A purchase order issued to a vendor.

id · string<uuid>

object · enum<string>

Available options: purchase_order

entity_id · string<uuid> · read-only

po_number · string · read-only

vendor_id · string<uuid>

location_id · string<uuid> | null

status · enum<string> · read-only

Available options: draft, approved, sent, partially_received, received, closed, cancelled

po_date · string<date-time>

expected_date · string<date-time> | null

subtotal · number

tax_total · number

shipping_total · number

po_total · number

currency · string · default: USD

notes · string | null

internal_notes · string | null

metadata · object | null

created_at · string<date-time> · read-only

updated_at · string<date-time> · read-only

approved_total · number | null · read-only

The order total as it stood when an approver approved this purchase order -- the basis they actually saw. NULL on every approval predating 2026-08-17 (no backfill) and NULL means "basis unknown", which is treated as fail-safe.

approval_stale · boolean · read-only

DERIVED, not stored. True when the order is approved AND its total has since risen above approved_total. The purchase order still receives normally; this is a non-blocking prompt to re-approve.

header_editability · object · read-only

Per-field verdicts for the header fields, from the same predicate the write handlers enforce. Keys: notes, internal_notes, due_date, expected_date, location_id, po_tracking_reference. Each is { allowed: boolean, reason: string|null } where reason is a token from the PoLineEditReason vocabulary.

Show child attributes

billed_total · number · read-only

How much of this purchase order's commitment a vendor bill has already taken over: the sum of total over every linked bill in open, partial, paid or written_off. 0 when no bill has been raised, never null.

unbilled_balance · number · read-only

What the purchase order STILL commits the buyer to: max(order_total - billed_total, 0), cents-quantized. Read this rather than balance_due, which on a purchase order is the ORIGINAL COMMITMENT the header was raised for and is never decremented when a bill is raised (the payable is the bill). Clamped at zero because a vendor may add freight on the bill and over-bill the order.