List shifts
List your shifts that overlap a time range, past or upcoming, to find the id that
POST /v1/shifts/{shift_id}/operator and POST /v1/shifts/{shift_id}/defects take.
A shift is returned when any part of it falls between from and to: it ends after from and
starts before to. So a night shift from 22:00 to 06:00 shows up in a range covering either
day. The range may span at most 31 days; page through longer periods with consecutive
ranges. Shifts come back ordered by start, then by machine.
Narrow the list with machineId, repeated for several machines:
GET /v1/shifts?from=2026-10-12T00:00:00Z&to=2026-10-13T00:00:00Z&machineId=12
Shifts excluded from metrics are listed too, with isConsidered: false.
Query Parameters
Return shifts that end after this moment. A time without a UTC offset is read as UTC.
date-timeReturn shifts that start before this moment, at most 31 days after from. A time without a UTC offset is read as UTC.
date-timeOnly shifts of these machines, as returned by GET /v1/machines. Repeat it for several machines (machineId=12&machineId=13). All of your machines when omitted.
Response Body
application/json
application/json
curl -X GET "https://example.com/v1/shifts?from=2026-10-12T00%3A00%3A00Z&to=2026-10-13T00%3A00%3A00Z"[ { "id": 48213, "machineId": 12, "title": "Morning", "start": "2026-10-12T06:00:00Z", "end": "2026-10-12T14:00:00Z", "targetQuantity": 1200, "isConsidered": true }]Stops report POST
Return individual machine stops with their duration, cause and classification. This is the drill-down behind the downtime totals in the metrics report. `stopId` accepts the full comparison grammar, so a specific stop or a range of them can be pulled directly.
Set shift targets PUT
Set the production target of existing shifts, for upcoming or past days. The body is a JSON **array** of up to 1,000 rows, so a whole plan (or a CSV export of one) fits in one call. Each row names a shift by its machine (`uuid` or `name`), the `date` it starts on in the company's timezone, and its `title` (for example `Morning`). Sending the same values again is harmless: the target is overwritten, not added to. Every row comes back with a `status`, and only `updated` rows changed anything: * `updated`: the shift's target is now `targetQuantity`. * `machineNotFound` / `ambiguousMachine`: no machine, or more than one, matches `machine`. * `shiftNotFound` / `ambiguousShift`: the machine has no shift, or more than one, with that title starting on that date. * `duplicateShift`: another row in the same request points at the same shift, so neither was applied. Targets are read live from the shift, so realtime and shift views show the new value right away. Nothing is recalculated: the target is not an input to OEE.