Search Production Logs

Create one or many Production Logs. The body is a JSON array, even for a single record. This is the endpoint an MES, ERP or shop-floor terminal uses to push production into Pulsar. machine and sku are references that accept either an id or a name, so a system that only knows line names and product codes does not have to resolve Pulsar ids first. A Production Log describes a closed interval: start and end are both required, end is at or after start, and both fall inside a single shift of the machine. Past shifts are accepted, so logs can be sent days after production. To record what is happening in the shift a machine is running right now, use the realtime endpoints instead. Defects (type: "defects") are additive. Several defects logs may cover the same range, in one request or across requests, and each one is recorded, so sending the same batch twice records it twice. Send each batch once, and retry it only as described under Retries and Idempotency-Key below. start and end may be the same instant for defects found at one point in time: `json [ {"type": "defects", "count": 3, "nominalSpeed": 60, "machine": {"name": "Press 4"}, "sku": {"name": "GAL-1042"}, "start": "2026-10-12T14:00:00Z", "end": "2026-10-12T22:00:00Z"}, {"type": "defects", "count": 1, "nominalSpeed": 60, "machine": {"name": "Press 4"}, "sku": {"name": "GAL-1042"}, "start": "2026-10-12T17:42:10Z", "end": "2026-10-12T17:42:10Z"} ] ` total and correct logs may not overlap another log of the same type, machine and SKU. The response lists the logs of this request. Quality and OEE for the affected shifts are recalculated in the background, usually within minutes. Retries and Idempotency-Key. Whether a failed call recorded anything depends on how it failed: * A 4xx response means the request was rejected and nothing was recorded. Fix it and send it again. * A timeout, a dropped connection or a 5xx response leaves the outcome unknown: the request may have been recorded even though you never got the response. Sent again without an Idempotency-Key, it can be recorded twice, so first check whether it was recorded, for example with POST /v1/production-logs/filters. To retry safely instead, send an Idempotency-Key header with a unique value you generate for each request, such as a UUID, and send the same key and the same body on every retry of that request. The key is stored together with what the request recorded, so a retry never records it twice: * If the original request was recorded, the retry records nothing and returns the original response, with the header Idempotent-Replayed: true. * If the original was not recorded, whether it was rejected or failed, the retry is processed as a new request. * Reusing a key with a different request, another body or URL, returns 409. * In the rare case that the original is still being processed, the retry returns 409. Retry again shortly. Keys are scoped to your company, so all of its API keys share them, and each key is kept for 24 hours after the request that recorded it. After that, a request with the same key is processed as a new one, so retry within that window.