GraphQL Mutations (Write)

From the Business tier, the GraphQL endpoint supports 10 write mutations: create/update/delete on Work Orders, Assets and Parts. Mutations delegate to the same underlying services as REST, so audit logs, notifications and reference auto-generation (WO-XX, ASS-XX, PART-XX) all work consistently.

Available mutations

• createWorkOrder(input) → WorkOrder
• updateWorkOrder(id, input) → WorkOrder
• deleteWorkOrder(id) → DeleteResult
• createAsset(input) → Asset
• updateAsset(id, input) → Asset
• deleteAsset(id, force?) → DeleteResult
• createPart(input) → Part
• updatePart(id, input) → Part
• deletePart(id, force?) → DeleteResult
• adjustStock(id, quantity, reason?) → Part — apply a signed stock delta (e.g. -1 to dispense one unit); atomic with a StockMovement audit row, never goes negative

Input shape

Each mutation has an InputType with safe fields only — companyId, sequenceNumber, reference and createdById are filled server-side. You only pass title, description, status, priority, assetId, locationId, etc. Part inputs also accept barcode, maxStockLevel, locationId and vendorId, and quantity/minQuantity/maxStockLevel take decimals (e.g. 0.5).

Example: create a work order

mutation($i: WorkOrderCreateInput!) { createWorkOrder(input: $i) { id title reference status createdAt } } with variables {"i": {"title": "Pump #3 leak", "priority": "HIGH"}}.

Adjusting stock

To change a part's quantity, use adjustStock with a signed delta — negative to consume, positive to receive. It updates the quantity and writes a StockMovement audit row in one atomic transaction, and never lets stock fall below zero. Prefer it over updatePart(quantity), which sets an absolute value and records no stock history.

Attribution

Public API requests don't have a logged-in user, so mutations are attributed to the first ADMIN of the company (or any active user as fallback). Audit logs always show a real human, never NULL.

Common errors

• GRAPHQL_VALIDATION_FAILED — input shape doesn't match (e.g. missing required title)
• BAD_REQUEST — value validation failed (e.g. title > 500 chars)
• FORBIDDEN — your tier is below Business
• NOT_FOUND — id doesn't exist or belongs to another company
• FORBIDDEN — the key's access level is too low (e.g. a READ key calling a mutation)