API v4 Release Notes — August 28, 2026

New

• Lookup catalogs for the ids a create requires — 18 new read-only resources, each with GET /v4/{resource} and GET /v4/{resource}/{id}, so you can resolve ids instead of hardcoding them: note_types, ticket_types, work_order_types, work_order_actions, equipment, equipment_statuses, equipment_wire_types, invoice_billable_items, invoice_terms, customer_payment_types, billing_types, tags, dealer_numbers, discount_affiliates, customer_cancel_reasons, funder_reasons, adt_monitoring_system_types, and interactive_services_providers. Each is gated by the permission for the write it feeds, and every resource page now links the catalog behind each id field.
• POST /v4/calendar_events/available_users — returns the techs or sales reps who can be assigned an appointment for a customer, as { user_id, name, fname, lname, eligible }. Pass user_ids to test specific people, list_mode to pick techs by office location or coverage area, and a start_from/start_to (or start_time/duration) window to also get busy, includes_time_off, and conflicts.
• POST /v4/calendar_events/available_slots — returns the configured tech time slots that are open for a customer, for companies using time-slot scheduling. customer_id plus a start_from/start_to window are required; the window may not exceed the company's days-per-page setting (capped at 31). Companies not on slot scheduling get 422 slot_scheduler_not_enabled.
• Query-shaped collection actions — a collection action can now answer with 200 and a non-resource payload in data, instead of 201 and a record. The two calendar lookups above are the first; meta.data is unchanged for record actions.

Changed

• ⚠ Breaking: catalog lists now return only items that are turned on. GET /v4/account_classes, activation_fee, customer_warranties, funders, lead_company_campaigns, lead_dispositions, lead_types, mmrs, monitoring_companies, and terms previously returned inactive items too. Add ?active=false for off items only or ?active=all for both; anything else returns 422. GET /{id} is unchanged — an off item still resolves so existing records read. monitoring_plans and lead_companies have no on/off flag and are unaffected.
• ⚠ Breaking: PATCH /v4/customer_invoices/{id} restricts type changes. The only accepted transition is quote → invoice. Any other change — invoice → quote, for example — now returns 422. Re-sending the current type unchanged still passes.
• GET /v4/customers accepts ?location_id= — an exact integer match that narrows the already permission-scoped page. A location you cannot view returns an empty page, not 403.
• New catalog filters — equipment filters on sku, model, manufacturer, and equipment_type_id; invoice_billable_items on code, description, and invoice_billable_item_class_id; dealer_numbers on number; customer_cancel_reasons on dealer_code; equipment_wire_types on abbr; tags on object_context; interactive_services_providers on interactive_services_provider_type_id. Every catalog with an on/off flag also accepts ?active=.
• Text filters treat % and _ literally. A name= (or other LIKE) filter value containing those characters is now matched as text rather than as a SQL wildcard pattern.
• customer_payments returns is_parent_rollup — read-only, identifying consolidated parent payments produced by the nightly parent/child billing rollup.
• message_logs returns resource_id and message_batch_id — resource_id is a plain, joinable copy of the related record's primary key (null where the key is composite, such as calendar_events; resource_type_instance_id stays authoritative there). message_batch_id groups every row produced by one physical send, so twelve rows from one consolidated email are distinguishable from twelve separate sends.
• invoice_recurring normalizes per-child email flags on rolled-up rows. When the customer is a sub-customer linked by parent/child billing (bill_with_parent = 1), send_on_generation and send_on_attempted_processing are accepted on POST/PATCH but persist as false — the response body shows the stored state. Delivery for those invoices is the consolidated parent digest. Standalone customers are unaffected.
• users title fields moved to their own permission. hierarchy_title_id and hierarchy_title_designation are now in a title section gated by the new User Titles permission; existing Organizational Hierarchy grants were carried over at rollout, so current access is preserved. recruited_by_user_id moved to the HR section and now needs only the HR permission, matching every other surface.
• POST / PATCH /v4/customers can reject an unlicensed sales rep. For companies that enable the setting, assigning a rep_id whose user lacks the government licenses required for the customer's state, city, or county returns 422 anchored to rep_id. Only a new assignment is checked: any create, or an update that changes rep_id or converts a lead to a customer.
• API usage is metered. API requests draw SecurityTrax Tokens from your company's token wallet. Creating customers and leads (POST /v4/customers) is included with your subscription and never draws tokens; your administrators can review the published rate in SecurityTrax.
• Rate-limit thresholds are no longer published. The three levels — per IP address, per API access token, and per company — still apply, but the specific numbers have been removed from the reference because they differ per deployment, are adjusted per company, and change over time. Build against the Retry-After header on 429 rate_limited rather than a rate you inferred.
• Tokens are now called "API access tokens." Renamed from "personal access token" across the documentation and the SecurityTrax UI. The token format, the Authorization header, and every endpoint are unchanged.

Fixed

• POST / PATCH / DELETE /v4/customer_equipment no longer double-deducts or double-credits technician inventory. For companies using the install-status-required adjustment mode, stock now moves only while the row's install status is installed or removed — a row at needs install with a technician assigned is pre-allocated, not deducted. Deleting a row credits the technician only when stock was actually out with them.