Work Order Actions

Reference for the work_order_actions resource. Requests follow the conventions in Requests and Responses; fields you receive and may write are filtered by your user's permissions, so responses can contain a subset of the fields below.

Operations

Not available as a standard REST operation for this resource: create, update, delete — such requests return 402 feature_not_enabled or 403 permission_denied.

How it works

work_order_actions is the read-only catalog of work needed on a piece of equipment — the valid work_order_action_id values on work order to equipment. This is a global 3-row table (id + name only; no status or on/off flag).

Ids are platform-seeded and stable:

Visible to any caller holding Customer Work Orders or Lead Notes. The list is the full table.

curl "https://portal.securitytrax.com/acme/user/v4/work_order_actions" \
  -H "Authorization: Bearer stx_acme_..."

Filter by name (matches anywhere). Sort by id or name; GET /{id} fetches one.

Fields

Fields are grouped by the permission that gates them. A group you may not view is absent from responses; a group you may not write is rejected with 422 when sent in a write.

Work Order Action

View: any of: Customer Work Orders; Lead Notes.

Pagination

The list endpoint uses client-controlled offset pagination: ?page= (1-based) and ?per_page= (default 25, max 100). The response mirrors meta.pagination (page, per_page, total, last_page) and sends an RFC5988 Link header; follow rel="next" to walk pages. See Pagination.

Filters

The list endpoint accepts these query-param filters: name. An unsupported filter parameter returns 422. See Filtering collections for matching semantics.

Sorting

GET .../work_order_actions?sort= orders the list by: id, name. Prefix a field with - for descending; comma-separate for tie-breakers. An unsupported field returns 422. See Sorting collections.

Related

• Requests and Responses — envelope, errors, pagination, and rate limits.
• Authentication — API access tokens and the Authorization header.