Skip to main content

Installed equipment

Installed equipment is available at /equipment. Each item belongs to a location and may reference an HVAC system at that same location. Use location_id to join /locations and its complete account associations. Equipment’s account_id filter includes archived location/account associations as well as current ones. All operational statuses are returned by default, including deactivated items. Exact filters include location, HVAC system, equipment type, manufacturer, condition, and repeated status values. Recorded legacy or custom classification strings remain available.
Equipment lifecycle and warranty dates are recorded calendar dates. They do not establish calculated age, replacement probability, current warranty eligibility, or equipment-specific service history. Duplicate serial numbers do not make two records the same item. The API preserves nullable legacy creation/update timestamps; it does not substitute another date. Form responses include complete recorded answers, including signature data URIs, so page size bounds parent count rather than response bytes. For forms with large media strings or many questions, start with limit=10 and lower it if needed; children are never silently truncated. Both equipment and form-response collections order by immutable ID ascending. Creation bounds exclude unavailable creation dates. Follow next_cursor with the same filters, changing page size as needed.

Form instances and relationships

Form responses contain a captured name, instance number/label, ad-hoc state, and the complete question/answer set from the original appointment. Follow-up jobs can reuse a response in the app; the API returns that instance once with its original job_id and appointment_id. form_id identifies the source form for grouping. Current template edits do not replace captured questions or names. Filters include original job/appointment, account/location, source form, business unit, job type/class, last saver, and ad-hoc state. Use /jobs and /team-members to join work dimensions and recorded savers.

Questions and answers

Questions retain captured labels, types, required/photo requirements, helper text, and section context. Dual-column inputs are interleaved by row in display order. question_id is nullable for legacy content and is not guaranteed stable across revisions. answer_path is local to the captured instance, such as /items/2/right/0/response; it changes if the captured structure is reordered. Replace the complete question set when refreshing an instance, rather than treating question labels or paths as global IDs. Every answer is a string or null. No, false, 0, and the empty string remain distinct from an absent answer. Rich-text TEXT values become plain text; other types retain the recorded string. PHOTO normally contains a CDN URL and SIGNATURE normally contains a PNG data URI. An associated photo is a separate recorded string. These are captured values, not verified attachment references or newly signed links; the API does not fetch media. If a captured structure is unsupported or malformed, questions and completed are null together while safe instance metadata remains available. Null questions mean unavailable content, not an empty form.

Completion semantics

completed follows the existing required-answer and required-photo check on the original capture, before TEXT conversion. It is not a recorded submission, approval, completion event, or verified signature. Empty/title-only/optional-only forms may be complete. Whitespace and HTML-only strings follow the app’s existing presence rules. Required associated photos matter even for optional answers; PHOTO inputs use their own value. Customers can segment this response value locally; there is no completion filter or invented completion timestamp.

Refreshes and deletions

For both collections, updated_since covers parent-row saves only. Equipment can change through its related system/location/account data without its own timestamp advancing. A form’s last editor and update timestamp mean last save: the app can save several instances together when only one changed. Parent work dimensions and template edits do not become form save events. Refresh known IDs or broader scopes when those relationships matter. Both resources can be hard-deleted and provide no tombstone or guaranteed deletion feed. Collection and detail representations are identical, including complete questions/media; smaller parent-page limits help with large captured forms.