Welcome to the Coperniq API release notes. This section highlights noteworthy changes across endpoints, schemas, and docs.

Recent highlights

  • New: AHJs — GET /ahjs (search, filter, and lat+lng geo lookup), GET /ahjs/{id}, and PATCH /ahjs/{id} to update custom property values. v2 mirrors these under /v2 with the standard success envelope.
  • Updated: GET /properties — now documents the ahj record type (custom AHJ properties only) and adds an isCustom boolean to every property to distinguish custom columns from built-in standard ones.
  • New: Sections — line items on projects, invoices, and bills can now be grouped into named sections (matching quotes and work orders); read responses expose sectionName per line item.
  • New: Vendors — full CRUD via GET/POST /vendors, GET/PATCH/DELETE /vendors/{vendorId}, GET /vendors/search, and many-to-many project linking via POST/DELETE /projects/{projectId}/vendors/{vendorId}. Vendor-specific fields: vendorType (enum), website, and projectIds.
  • New: Labels — GET /labels (filter by type), POST /labels, GET /labels/{labelId}. type is WORK (work orders) or ASSET. v2 mirrors these under /v2 with the standard success envelope.
  • New: Assets — GET /assets (filter by account_id), POST /assets, GET/PATCH /assets/{assetId} (set isArchived: true via PATCH to archive). v2 mirrors these under /v2 with the standard success envelope.

Looking for a specific date? See the entries below.

Summary

Today’s release adds request/client work order endpoints, consolidates visit schemas, and completes the comments API across projects/requests/clients. We also improved the docs’ structure and fixed operation IDs for navigation.

What’s new?

  • Request Work Orders: List, create, and update request work orders.
  • Client Work Orders: List and create client work orders.
  • Comments API: List/create/update/delete comments for projects, requests, and clients.

Changes

  • Work Orders
    • POST /projects/{projectId}/work-orders requires templateId and accepts optional phaseInstanceId (phase must be started when provided).
    • POST /requests/{requestId}/work-orders requires templateId, optional phaseInstanceId (phase doesn’t need to be started).
    • POST /clients/{clientId}/work-orders requires templateId (no phases).
    • GET /requests/{requestId}/work-orders lists request work orders.
    • PATCH /requests/{requestId}/work-orders/{workOrderId} updates a request work order.
  • Comments
    • Projects: GET /projects/{projectId}/comments, POST /projects/{projectId}/comments, PATCH /projects/{projectId}/comment/{commentId}, DELETE /projects/{projectId}/comment/{commentId}.
    • Requests: GET /requests/{requestId}/comments, POST /requests/{requestId}/comments, PATCH /requests/{requestId}/comment/{commentId}, DELETE /requests/{requestId}/comment/{commentId}.
    • Clients: GET /clients/{clientId}/comments, POST /clients/{clientId}/comments, PATCH /clients/{clientId}/comment/{commentId}, DELETE /clients/{clientId}/comment/{commentId}.
  • Projects
    • GET /projects/{projectId} includes phaseInstances array (phase data).
  • Requests
    • GET /requests/{requestId} includes phaseInstances array (phase data).
  • Catalog Items
    • Cleaned up examples and aligned schemas with public shape.

Notes

  • For project work order creation, when phaseInstanceId is provided, the phase must already be started.
  • Request work order creation does not require a started phase.