Skip to main content
GET
cURL

Authorizations

​
X-Session-Token
string
header
required

Session token for authentication.

Headers

​
If-None-Match
string

A previously returned ETag. If it still matches the current representation the server responds 304 Not Modified with no body; otherwise the full representation is returned with a fresh ETag.

Query Parameters

​
include
enum<string>[]

A comma separated list of related resources to include.

Available options:
appointment,
assignees,
forms,
locations,
operation_type,
organisation,
permits,
properties,
scheme,
streets,
teams,
template,
work_order
​
filter
string
default:""

Filters the response data based on the value provided.

Available filters:

  • in(id,[xxx]): Filter by ID(s)
  • in_schemes: Filter for operations that are part of a scheme(s) by their ID(s)
  • in_work_orders: Filter for operations that are part of a work order(s) by their ID(s)
  • assigned_to: Filter for operations assigned to a user(s) by their ID(s)
  • at_properties: Filter for operations at a property(s) by their ID(s)
  • unscheduled: Filter for unscheduled operations
  • no_start: Filter operations with no start time
  • no_end: Filter operations with no end time
  • has_appointment: Filter operations that have appointments
  • no_appointment: Filter operations that do not have appointments
  • eq(unallocated,true): Filter for operations with no work order (and so no scheme). eq(unallocated,false) returns operations that have a work order. Any other value matches nothing. It combines with other terms inside and(...) or or(...), for example and(eq(unallocated,true),eq(status,todo)). Inside or(...) it narrows only its own term. Unallocated operations can only exist when the organisation has the governance.unallocated_operations feature enabled.
  • has_property: Filter operations that have any related property - this does not accept arguments, it just checks for the existence of a related property. You can use at_properties to find operations at a specific property.

Project-role filters (cross-resource lookups against project role assignments):

  • has_role(<project_role_id>): Filter for operations that have at least one active assignment for the given project role. Example: has_role(11111111-1111-1111-1111-111111111111).
  • held_by(<user_id>): Filter for operations where the given user holds at least one role (any role). Example: held_by(22222222-2222-2222-2222-222222222222).
  • has_role_assignment(<project_role_id>,<user_id>): Filter for operations where the given user holds the given role specifically. Example: has_role_assignment(11111111-1111-1111-1111-111111111111,22222222-2222-2222-2222-222222222222).

Field filters (RQL expressions on Operation fields):

  • id: Filter by operation ID. Example: eq(id,11111111-1111-1111-1111-111111111111), or multiple with in(id,[<uuid>,<uuid>]).
  • organisation: Filter by owning organisation ID. Example: eq(organisation,<uuid>).
  • scheme: Filter by scheme ID. Example: eq(scheme,<uuid>), or multiple with in(scheme,[<uuid>,<uuid>]).
  • work-order: Filter by work order ID. Example: eq(work-order,<uuid>), or multiple with in(work-order,[<uuid>,<uuid>]).
  • type: Filter by operation type ID. Example: eq(type,<uuid>).
  • name: Filter by name. Example: eq(name,Excavation), or partial match with contains(name,exc).
  • assignees: Filter by assigned user ID. Matches operations that include the given user. Example: eq(assignees,<uuid>), or multiple with in(assignees,[<uuid>,<uuid>]).
  • properties: Filter by related property ID. Matches operations that include the given property. Example: eq(properties,<uuid>), or multiple with in(properties,[<uuid>,<uuid>]).
  • appointment: Filter by appointment ID. Example: eq(appointment,<uuid>).
  • status: Filter by status. Accepts todo, in_progress, done. Example: in(status,[todo,in_progress]).
  • done_reason: Filter by reason an operation is done. Accepts completed, cancelled, aborted. Only meaningful for operations whose status is done. Example: and(eq(status,done),in(done_reason,[completed,cancelled])).
  • dates.scheduled.start: Filter by scheduled start date. Accepts an RFC 3339 timestamp and supports the range operators ge, le, gt, lt (and eq). Example: ge(dates.scheduled.start,2026-07-01T00:00:00Z).
  • dates.scheduled.end: Filter by scheduled end date. Accepts an RFC 3339 timestamp and supports the range operators ge, le, gt, lt (and eq). Example: le(dates.scheduled.end,2026-07-14T23:59:59Z).
  • updated_at: Filter by the date an operation was last modified. Accepts an RFC 3339 timestamp and supports the range operators ge, le, gt, lt (and eq). Example (modified since a given time): ge(updated_at,2026-07-01T00:00:00Z). Example (modified within a window): and(ge(updated_at,2026-07-01T00:00:00Z),le(updated_at,2026-07-14T23:59:59Z)).

For more information on using named filters, see the docs

​
limit
integer<int64>
default:100

Limit the number of resources returned by the API

Required range: x >= 1
​
offset
integer<int64>
default:0

Offset the resources returned by the API

Required range: x >= 0
​
page
object

JSON:API pagination, as page[limit] and page[offset]. The same as the top-level limit and offset parameters; when both forms are sent, page[...] wins.

​
sort
enum<string>[]

A comma separated list of fields to sort by.

Available options:
code,
-code,
created_at,
-created_at,
name,
-name,
postcode,
-postcode,
updated_at,
-updated_at

Response

List of operations.

JSON API response object

​
data
A list of operations · object[]
required
​
meta
object
required
​
jsonapi
object
required
​
included
object[]

Related resources that can be included when an operation is returned

A form