Customer Equipment

Reference for the customer_equipment 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

Required on create: link customer under data.relationships — a create that omits it is rejected with 422 naming the relationship.

How it works

customer_equipment is the equipment installed on (or assigned to) a customer — one row per equipment line. It supports full CRUD plus a list endpoint.

A row belongs to a customer through customer_id, and its permission location is that customer's location: everything is gated by the Customer Equipment permission at the customer's location (leads use the lead-visibility rule).

Creating

POST /customer_equipment requires the customer parent (in data.relationships) and these attributes:

Costs are denormalized from the equipment master. The cost fields (equipment_cost, equipment_value, equipment_par, equipment_points, equipment_device_count, equipment_tech_bonus, equipment_installation_cost) are not set on create — they are copied from the linked equipment record automatically, exactly as the v1/v3 API does. They are read-only thereafter (SecurityTrax doesn't edit them either), returned on read but not writable.

curl -X POST "https://portal.securitytrax.com/acme/user/v4/customer_equipment" \
  -H "Authorization: Bearer stx_acme_..." \
  -H "Content-Type: application/json" \
  -d '{"data":{"attributes":{"equipment_id":42,"quantity":2,"user_id":7,"equipment_status_id":1,"item_charge":"49.99"},"relationships":{"customer":{"data":{"type":"customers","id":100}}}}}'

Inventory side-effects

Writes move real inventory, exactly like the in-app screens:

• Create/Update with an install or uninstall inventory technician set transfers on-hand stock to/from that tech (the equipment ledger). Changing the status or the inventory tech on a PATCH rebalances the ledger. Companies using the install-status-required adjustment mode only move stock while the install status is installed or removed — a row at needs install with a tech assigned counts as pre-allocated, not yet deducted.
• Delete soft-deletes the row, returns any allocated inventory to the technician, and removes the row's work-order equipment links. The return is conditional on stock actually being out with that technician — deleting a row whose stock was never deducted does not credit them.

So a POST/PATCH/DELETE here is not a bare row write — treat it as the same operation the equipment screen performs.

Because these writes move inventory, the fields that drive them require the inventory-settings permission on top of Customer Equipment — matching the in-app screen:

• install_inventory_tech_id, uninstall_inventory_tech_id, install_tech_schedule_id, uninstall_tech_schedule_id — require it to set or change (they default to 0, so you can create equipment without them).
• equipment_status_id — required on create (no extra permission there), but requires the inventory-settings permission to change afterward.
• quantity is create-only (see above) and can't be changed at all.

Without the inventory-settings permission, a write that touches those fields is rejected; a write that leaves them alone succeeds with just Customer Equipment.

Read-only fields

Returned on read but not writable (managed by the app / integrations, and not editable in the SecurityTrax UI):

• the cost fields (above) — denormalized from the equipment master;
• central_station_id / interactive_services_id — the monitoring / interactive- services linkage;
• is_paid_for — a billing flag driven by payment flows.

Listing

GET /customer_equipment returns non-deleted rows at locations where you can view customer equipment. Filters (all optional, combinable):

Sortable: id, customer_id, equipment_id, equipment_status_id, user_id, quantity, created_at, updated_at. Add ?count_only=true to get just the total without the rows.

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.

Equipment

View: customers — Customer Equipment at the record's location; leads — the standard canViewLead rules. Create: Customer Equipment at the record's location. Update: Customer Equipment at the record's location.

Quantity

View: customers — Customer Equipment at the record's location; leads — the standard canViewLead rules. Create: Customer Equipment at the record's location.

Inventory Techs

View: customers — Customer Equipment at the record's location; leads — the standard canViewLead rules. Create: all of: Customer Equipment at the record's location; the standard canManageCustomerEquipmentItemInventorySettings rules. Update: all of: Customer Equipment at the record's location; the standard canManageCustomerEquipmentItemInventorySettings rules.

Equipment Status

View: customers — Customer Equipment at the record's location; leads — the standard canViewLead rules. Create: Customer Equipment at the record's location. Update: all of: Customer Equipment at the record's location; the standard canManageCustomerEquipmentItemInventorySettings rules.

Is Paid For

View: customers — Customer Equipment at the record's location; leads — the standard canViewLead rules.

Costs

View: Customer Equipment at the record's location.

External Connections

View: any of: Customer Equipment at the record's location; any of: Customer ADT at the record's location; Customer Monitronics at the record's location; Customer CMS at the record's location; Customer Affiliated Monitoring at the record's location; Customer Rapid Response at the record's location; Customer Avant Guard at the record's location; Customer United Central Control at the record's location; Customer Safe at the record's location; Customer All American Monitoring at the record's location; Customer API at the record's location; any of: Customer Alarm Dot Com at the record's location; Customer Secure Net at the record's location; Customer at the record's location.

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: customer_id, equipment_id, equipment_status_id, user_id, created_at_from, created_at_to, updated_at_from, updated_at_to. An unsupported filter parameter returns 422. See Filtering collections for matching semantics.

Sorting

GET .../customer_equipment?sort= orders the list by: id, customer_id, equipment_id, equipment_status_id, user_id, quantity, created_at, updated_at. 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 — tokens and the Authorization header.