Correct a timer
PATCHhttps://
Partially updates a timer: absent keys are untouched, an empty body is rejected.
Access
- Token scope
- api:
write: hours Without it:
403 insufficient-token-scope. - Permission
- None. The record's own rules still apply.
- Rate cost
- 1 unit, write bucket. A write costs the same whatever
viewyou ask for. - Also
- Accepts
If-Match. Never cached:private, no-store. Unknown body keys are refused, never dropped.
Both are checked, scope first. A token never does more than its user. How access is checked
started_at is the only writable key; correcting a mis-started stopwatch is the whole purpose. The timeable_type / timeable_id pair is never accepted on a PATCH, so retargeting a timer is a DELETE followed by a POST. user_id is not accepted either, so a timer cannot be moved to another employee. Send If-Match with the ETag from your last read to detect a concurrent edit, which answers 412. Treat it as best-effort only: this resource carries no concurrency token, and updated_at is second-precision, so two writes inside the same second are indistinguishable. This operation declares no permission of its own: you may change your own timers, and changing another employee's timer additionally requires times::update_others.
Path parameters
Query parameters
Unknown parameters are refused with 400, naming the parameter.
Request headers
A correlation id of your own. It is recorded in our logs next to the server's request id but never returned: the response header always carries the server's id. A value that does not match the pattern is discarded silently, never rejected.
Request body
Unknown keys are refused with 422, naming the key.
Response 200
Returns a Timer in the detail view.
Headers
ETag- A strong validator of exactly this representation.
RateLimit- The IETF
httpapi-ratelimit-headersform of your remaining allowance on the tightest bucket this request touched. RateLimit-Policy- The ceiling and window of that bucket, as
<limit>;w=<seconds>. X-Request-Id- The server-generated ULID correlating this response with our logs.
Every response also carries Cache-Control, Vary, X-Content-Type-Options, X-Plnnrly-Api-Version, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset. Headers and versioning
Employee this timer belongs to. Always the authenticated user; a timer cannot be started for someone else.
The employee this timer belongs to. Expanding it with ?include=user additionally requires the users::read permission and a token scope covering the users prefix.
The kind of record timeable points at; it says which branch of timeable applies.
work_itemevent
New values may be added.
The record being timed. Expanding it with ?include=timeable additionally requires the read permission and token scope of the target's own prefix, per branch: project_management for a work item, events for a planning event.
Which form you get depends on timeable_type.
work_itemWorkItemSummaryeventEventSummary
When the stopwatch was started. Elapsed time is this value against the client's own clock; the API publishes no elapsed counter.
Errors
412 Precondition failed.
415 Unsupported media type.
422 Unprocessable content.
7 errors every operation can return: 400, 401, 404, 406, 429, 500, 503
400 Bad request.
idempotency-key-requiredinvalid-cursorinvalid-query-parametermalformed-requestunsupported-parameter
401 Unauthenticated.
404 Not found.
406 Not acceptable.
429 Too many requests.
500 Server error.
503 Service unavailable.
This path allows GET, PATCH, DELETE. Anything else answers 405.
Something wrong or missing on this page? Tell us