v1API ReferenceShifts

Add defects by time

Add defective units of a SKU to the shift that machine machineId was running at time, including shifts that have already ended. Use it when you know the machine and roughly when the defects were found, but not the shift id.

How defects add up. Unlike operators, defects have no timeline and no order. Each call adds a new defects production log of quantity units of the SKU, covering the whole shift, and the shift's Quality and OEE count it in the background. Calls never replace earlier ones:

  • Sending quantity: 2 and then quantity: 3 records 5 defects.
  • Sending the same request twice records the defects twice, so retry only requests that failed.
  • To undo a call, delete the log it returned with DELETE /v1/production-logs/{id}. To see what a shift already has, list its logs with POST /v1/production-logs/filters.

Defects are not attributed to any operator, and they can be added to past shifts, including ones whose production was reviewed. The SKU is given by id or by name; an unknown name creates a new SKU, so check the spelling.

Errors:

  • 400: no shift matches, the shift has not started yet, or the shift does not have enough production of that SKU to hold the defects.
  • 404: sku.id is not one of your SKUs.

Request Body

application/json

TypeScript Definitions

Use the request body type in TypeScript.

Response Body

application/json

application/json

Try it live
POST
/v1/shifts/defects

This endpoint requires authentication — paste a token in the Authorization section below.

curl -X POST "https://example.com/v1/shifts/defects" \  -H "Content-Type: application/json" \  -d '{    "sku": {},    "machineId": 12,    "time": "2026-10-12T10:00:00Z"  }'
{  "id": "5b0f6a52-3c1e-4d5b-9f0e-8a7c6d5e4f3a",  "shiftId": 48213,  "machineId": 12,  "quantity": 3,  "start": "2026-10-12T06:00:00Z",  "end": "2026-10-12T14:00:00Z"}

Assign shift operator POST

Assign an operator to a shift by its id (as returned by `GET /v1/shifts`), including shifts that have already ended. Without `start`, the operator takes over from the start of the shift. **How operator assignments add up.** Each shift keeps a timeline of who ran the machine. An assignment means "from `start` on, this operator runs the machine": it lasts until the end of the shift, or until the next assignment. * **First assignment.** If nobody is assigned to the shift yet, the operator covers the **whole shift**, from its first minute, even when `start` is later. * **Later assignments.** Each one splits the timeline at `start`: whoever held the machine keeps it until `start`, and the new operator takes it from `start` to the end of the shift. * **Order matters.** Send assignments in chronological order. A `start` earlier than the shift's latest change is rejected with `400`, so you cannot insert an operator in the middle afterwards. A `start` equal to the latest change replaces the operator who took over then. * **Retries are safe.** Sending the same assignment again changes nothing. * `start` is rounded down to the minute. For example, for a `Morning` shift from 06:00 to 14:00 with nobody assigned yet: | Request | Timeline after it | | --- | --- | | operator 1063 from 10:00 | 1063 06:00–14:00 (the first assignment covers the whole shift) | | operator 2071 from 10:00 | 1063 06:00–10:00, 2071 10:00–14:00 | | operator 3300 from 12:00 | 1063 06:00–10:00, 2071 10:00–12:00, 3300 12:00–14:00 | | operator 4410 from 08:00 | Rejected with `400`: 08:00 is before the latest change, 12:00 | To record a shift that had several operators, send the first from the start of the shift, then the others in the order they took over. Operator metrics for the shift are recalculated in the background, so reports may take a moment to show the change. Errors: * `400`: no shift matches, or `start` is outside the shift, in the future, or before the shift's latest operator change. * `403`: the shift has production marked as reviewed, which locks it. * `404`: the operator does not exist in your company.

Add shift defects POST

Add defective units of a SKU to a shift by its id (as returned by `GET /v1/shifts`), including shifts that have already ended. **How defects add up.** Unlike operators, defects have no timeline and no order. Each call adds a new defects production log of `quantity` units of the SKU, covering the whole shift, and the shift's Quality and OEE count it in the background. Calls never replace earlier ones: * Sending `quantity: 2` and then `quantity: 3` records 5 defects. * Sending the same request twice records the defects twice, so retry only requests that failed. * To undo a call, delete the log it returned with `DELETE /v1/production-logs/{id}`. To see what a shift already has, list its logs with `POST /v1/production-logs/filters`. Defects are not attributed to any operator, and they can be added to past shifts, including ones whose production was reviewed. The SKU is given by `id` or by `name`; an unknown name creates a new SKU, so check the spelling. Errors: * `400`: no shift matches, the shift has not started yet, or the shift does not have enough production of that SKU to hold the defects. * `404`: `sku.id` is not one of your SKUs.