Release Notes

File uploads: streaming support, reliability fixes, and limits

What’s new?

• Streamed multipart uploads for files:
  • POST /projects/{projectId}/files/upload
  • POST /requests/{requestId}/files/upload
• You can provide phaseInstanceId either as a form field or as a ?phaseInstanceId= query parameter; the API will include it once in the forwarded payload.

Fixes and improvements

• Robust parsing: files are fully consumed when building the outgoing multipart/form-data.
• Getting a project returns the project manager data.
• Allow files to be added in a certain project or request phase.

Usage notes

• Send multipart/form-data with a file part; optional fields may include phaseInstanceId.
• For non‑multipart uploads, send the raw bytes as the request body and pass filename/content type via:
  • Headers X-File-Name and X-File-Content-Type (case‑insensitive), or
  • Query params name and content_type.

Platform limits

• The API enforces a 10 MB request limit. With base64 encoding and multipart overhead, practical max payload is ~6–7 MB.
• For larger uploads, use an out‑of‑band approach (e.g., presigned upload) and then create the file record by URL.

Compatibility

• No response shape changes. Successful uploads return: id, name, downloadUrl, type, updatedAt, createdAt, companyId, metaData, source, createdByUser, isArchived.

Projects search endpoint

What’s new?

• Added GET /projects/search to query projects using up to two filters joined by logic (and/or).
• Supports standard fields (e.g., status, title, city, type, numeric/datetime fields) and custom properties by key name.
• Operators: eq, neq, gt, gte, lt, lte, contains, in, nin, between, exists.
• Pagination and sorting supported via page_size, page, and order_by.

Parameters

• prop1, op1, value1 (required)
• prop2, op2, value2 (optional)
• logic: and | or (default and)
• page_size, page, order_by

Value formats

• in/nin lists:
  • Plain CSV: value1=ACTIVE,ON_HOLD
  • Quoted CSV (values with commas): value1="Last, First",Other
  • JSON array: value1=["Last, First","Other"]
• between ranges:
  • Dates: value1=2025-01-01,2025-12-31
  • Numbers: value1=10000,50000

Examples

• Status equals ACTIVE:
  • GET /v1/projects/search?prop1=status&op1=eq&value1=ACTIVE
• Title contains “Solar”:
  • GET /v1/projects/search?prop1=name&op1=contains&value1=Solar
• Status IN (ACTIVE, ON_HOLD) AND city = Austin:
  • GET /v1/projects/search?prop1=status&op1=in&value1=ACTIVE,ON_HOLD&logic=and&prop2=city&op2=eq&value2=Austin
• Custom multiselect includes any of [“1”, “Option, with a comma”]:
  • GET /v1/projects/search?prop1=custom_multiselect&op1=in&value1=["1","Option, with a comma"]
• Updated within 2025:
  • GET /v1/projects/search?prop1=updatedAt&op1=between&value1=2025-01-01,2025-12-31

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.

Today’s release focuses on improving Work Orders creation, tightening schemas, and cleaning up the docs.

What’s new?

• Create Work Order: You can now create a work order under a specific phase instance using templateId and phaseInstanceId. The response includes id, createdAt, updatedAt, description, position, phaseInstanceId, projectId, and createdById.
• Full CRUD on Catalog Items: You can now, get, create, update, and delete catalog items in your company settings.
• Form Retrieval: You can now get forms on a project and get form details.
• Project Phase Instances: Getting a project by ID now includes the phase instances for that project.

Changes

• Work Orders
  • POST /projects/{projectId}/work-orders requires templateId and phaseInstanceId.
• Catalogs & Catalog Items
  • GET /catalog-items returns catalogs with their catalog items.
  • GET /catalog-items/{catalogItemId} returns a catalog item.
  • POST /catalog-items creates a catalog item.
  • PATCH /catalog-items/{catalogItemId} updates a catalog item.
• Forms
  • GET /projects/{projectId}/forms returns a list of the forms on a project.
  • GET /forms/{formId} returns the form details, including field values.
• Projects
  • GET /projects/{projectId} includes an array of phaseInstances.

Notes

• The provided phaseInstanceId must belong to the project where the work order is created.