Skip to main content
The Public REST API gives trusted server-side integrations access to their allowed workspaces, Trellis tasks, checklist actions, durable task photos copied from external sources, task tags, assignable users, departments, properties, and workflow automations. It uses workspace API keys created in Settings > Developer.
This REST surface is intentionally narrow. Use the dedicated Workflow OpenAPI document for workflow definitions, runs, tests, approvals, and migration controls. Use documented MCP tools or contact Trellis support before building against other objects.

Base URL

Interactive reference:
OpenAPI document:
Workflow OpenAPI document:

Authentication

Send the workspace API key as a Bearer token:
Discover the workspaces available to a key before calling workspace-scoped routes:
Use the returned id as {workspaceId}. The response contains only the key’s owner workspace. Public REST calls do not require a Trellis web login session or browser cookie. Store API keys only in trusted server-side environments, and rotate a key from Settings > Developer if it is exposed. Keys created for a named server integration are single-workspace technical identities. The administrator who creates the key is retained for audit only and is not exposed as a user or assignee. Requests are limited to the key’s owner workspace and scopes, and the key remains active until it expires or an administrator of that workspace revokes it. RapidEye integration keys accept only the task read, create, update, and delete scopes plus the property-read, checklist, department, user, attachment, and task-tag scopes selected by the RapidEye preset. Wildcard, MCP, property-write, and other public scopes are rejected for this principal type. Task deletion uses Trellis soft-delete behavior and remains limited to the key’s owner workspace. With properties:read, a RapidEye key can list properties or retrieve one property by ID. These responses contain only id, name, internalName, internalCode, and status. Creating, updating, and deleting properties remain unavailable to RapidEye keys. MCP client keys remain member-based and inherit the creator’s active workspace membership and role. When creating a key for an integration, select only the scopes that integration needs. The interactive reference lists the required scope for each operation. You can also authenticate with an access token obtained from POST /api/v1/auth/token. See Authentication for details.
The linked OpenAPI spec (openapi.public.json) documents workspace API key authentication only. Session access tokens work at runtime but are not reflected in the generated spec.

Contract versions

Breaking changes require a new object contract version or a new REST API version.

Endpoints

Workspace discovery

Properties

Tasks

Task checklist actions, attachments, and tags

Workspace lookups

Workflow automations

The Workflow API manages saved definitions and their immutable versions separately from executions. Use the dedicated Workflow OpenAPI document for all 48 operations and request schemas. Workflow API keys use three least-privilege scopes:
  • workflows:read reads definitions, versions, runs, tests, and related resources.
  • workflows:write creates or changes saved resources.
  • workflows:execute starts execution, activates a definition, resolves approvals, retries runs, and changes migration ownership.
Create and execution requests that declare Idempotency-Key can be retried safely with the same request body. Mutations that declare If-Match require the current ETag, which prevents one client from overwriting a newer change. Run requests return 202 Accepted; follow the response’s status URL until the run reaches a final state.

Pagination

List endpoints accept limit and offset. Responses include:

Properties

List properties

Supported filters: Property statuses: PROSPECT, ONBOARDING, ACTIVE, AT_RISK, INACTIVE.

Get a property

Create a property

Update a property

Delete a property

Property object

Additional room count fields (kitchens, livingRooms, hallways, terraces, balconies, gardens), stay limits (minNights, maxNights, minGuests), and deal tracking (dealValue) are also available. See the interactive reference or OpenAPI document for the full schema.

Tasks

List tasks

Supported filters: Task statuses: OPEN, CREATED, DRAFT, DRAFTED, SCHEDULED, IN_PROGRESS, FINISHED, CLOSED, PENDING_APPROVAL, REQUEST_APPROVED, REQUEST_REJECTED, COMPLETED. Task priorities: WATCH, LOWEST, LOW, NORMAL, HIGH, URGENT. Task sources: MANUAL, AUTOMATION, SCHEDULE_RULE, INTEGRATION, AI, REVIEW, MESSAGE, CALL, MEETING_BOT. Use the include query parameter to embed cost items and assignees in the task response:
When included, each task will contain:
  • costItems: Array of cost line items with amount, currency, description, billToType, categoryName, and notes.
  • assignees: Array of task assignees with role (PRIMARY or SECONDARY), type (USER or VENDOR), userId, vendorOrgId, and name.

Get a task

Create a task

Task creation uses the same Trellis mutation path as the app: assignees, tags, visit links, activity, notifications, automations, enrichment, and connected operational sync are handled by the normal task side-effect pipeline. Create request fields:

Update a task

Additional update-only fields: status, summary, completedAt, startedAt, sortOrder, projectId, billableToOwner, cost, costCurrency, isNoCharge, customFields, completionFields, replacePrimaryUser.

Delete a task

Task object

Additional fields for integrations, scheduling, vendor workflows, and AI provenance are also returned. See the interactive reference or OpenAPI document for the full schema.

External checklist actions

Use a linked checklist action when another service must finish work before the Trellis task can be completed. The same externalSource and externalId can be retried safely for one task.
The actionUrl must use HTTPS. Trellis displays it as the checklist action link without modifying the originating template. When externalSource is exactly rapideye, Trellis also appends one labeled inspection link to the existing task description and sends that description update to the connected operations provider. Retrying the same item does not duplicate the description link, and a pending or failed provider delivery can be retried safely. Other external sources remain Trellis-only. A required item with blocksCompletion: true prevents normal task completion until the item is completed. After the external work finishes, mark the item complete. Repeating this request preserves the first completion timestamp:

Durable task photos

The attachment operation downloads an existing public HTTPS image immediately and stores a durable copy in Trellis. Signed source URLs are supported: they only need to remain valid for the duration of the POST request.
The source must be reachable without cookies or provider-specific headers, use HTTPS, resolve only to public network addresses, return the declared image/* content type, and be no larger than 25 MB. Trellis records the downloaded byte count rather than trusting the optional sizeBytes hint. After the copy succeeds, Trellis keeps the durable internal URL and does not retain or return the signed source URL. For backward compatibility, both internalUrl and the legacy externalUrl response field point to the durable Trellis copy. The durable image is then queued through the same task-media sync used by the Trellis app; a linked operations provider such as Breezeway receives its own copy asynchronously. Repeating the same task, source, and external ID with the same API key returns the existing durable attachment without downloading it again. If that idempotency record predates durable storage, sending a fresh source URL backfills its Trellis copy.

Task tags

Discover the active tags that can be assigned to tasks:
Use a returned id to assign the tag idempotently:
Only active tags configured for tasks in the same workspace can be assigned. Removing an assignment is also idempotent, so retrying a successful delete returns success. Assignments and removals use the standard task-tag sync; tags mapped to the task’s linked operations provider are propagated there, while Trellis-only tags remain local.

Departments and assignable users

Use GET /workspaces/{workspaceId}/departments to find the departmentId required by task creation. Use GET /workspaces/{workspaceId}/users to list active assignees. The user response includes display name, role, membership ID, user ID, and department IDs; email addresses and phone numbers are not returned.

Daily work orders

The daily work orders endpoint returns tasks with status SCHEDULED in field-ops departments for a single calendar date, formatted as costed work orders with assignee details. Use it for daily operations reports and workforce cost summaries. Tasks in other statuses or non-field-ops departments are excluded.
Response:
When tasks use multiple currencies, totalCost is null, totalCostCurrency is "MIXED", and costTotalsByCurrency contains per-currency totals.

Errors