Update a furlough balance mutation
PATCHhttps://
Partially updates a mutation: absent keys are untouched, an empty body is rejected, and an unknown key is a 422.
Access
- Token scope
- api:
write: furlough Without it:
403 insufficient-token-scope. - Permission
- furlough::
manage Without it:
403 insufficient-permission. - 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
This is the API's only approval surface: {"is_approved": true} approves, {"is_approved": false} denies, and either needs furlough::manage, which is also this operation's own permission, so a plain employee cannot edit even their own pending request here although plnnrly lets them while it is still in the future. A manager deciding on their own mutation answers 403 forbidden-by-policy. ⚠ An approval through this endpoint is a plain field write: unlike the approval screen in plnnrly it does not split a request that spans two balance years into one mutation per year, and it sends the employee no e-mail. ⚠ start and end move as a pair (send both or neither), and neither rewrites year, so a period moved into another year keeps counting against the old balance year until year is sent too. 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.
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.
The balance year this mutation counts against. It is not derived from start: every balance sum counts by this year, so a mutation whose period moves into another year keeps counting against the year sent here until year is sent too.
Which leave balance this mutation moves. Regular and special leave are separate balances and never offset one another.
regular- Ordinary paid leave, drawn from the employee's regular annual balance.
special- Special leave: a separate balance granted for a specific entitlement, never offset against regular leave.
New values may be added.
The signed balance delta in minutes. Negative consumes balance (a leave request); positive grants it (a manager's adjustment, which requires the furlough::manage permission to write). The API never computes this from the employee's working week or the organisation's free days: send the exact number of minutes you mean.
A positive value grants balance and requires the furlough::manage permission; a caller with only furlough::create_for_yourself may write a negative value (a leave request) or zero. On a special mutation, the resulting special-leave balance for the year may not go negative.
Start of the period this mutation covers, in UTC. Equal to end on a manual balance adjustment, which covers no period at all.
Required when end is present.
End of the period this mutation covers, in UTC. Never before start, and equal to it on a manual balance adjustment.
Required when start is present. Must be on or after start.
The employee's or manager's own words for this mutation: the reason for the leave, or what the adjustment is for. The only field ?q= searches.
Response 200
Returns a FurloughBalanceMutation 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
The employee this mutation belongs to. Always the authenticated user on create and not writable.
The user who approved this mutation, set by the server when the mutation resolves to approved. Null while it is pending, and left null by a denial. Resolve the name through GET /api/v2/users/{user}.
The balance year this mutation counts against. It is not derived from start: every balance sum counts by this year, so a mutation whose period moves into another year keeps counting against the year sent here until year is sent too.
Which leave balance this mutation moves. Regular and special leave are separate balances and never offset one another.
regularspecial
New values may be added.
The signed balance delta in minutes. Negative consumes balance (a leave request); positive grants it (a manager's adjustment, which requires the furlough::manage permission to write). The API never computes this from the employee's working week or the organisation's free days: send the exact number of minutes you mean.
Start of the period this mutation covers, in UTC. Equal to end on a manual balance adjustment, which covers no period at all.
End of the period this mutation covers, in UTC. Never before start, and equal to it on a manual balance adjustment.
The employee's or manager's own words for this mutation: the reason for the leave, or what the adjustment is for. The only field ?q= searches.
Approval state, in three values: null means pending approval, true approved, false denied. The balance counts pending and approved mutations alike and ignores denied ones. Writing this field at all requires the furlough::manage permission.
The employee this mutation belongs to. Expanding it with ?include=user additionally requires the users::read permission and a token scope covering the users prefix.
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