Read a furlough balance mutation

GEThttps://<your-url>/api/v2/furlough-balance-mutations/{furlough_balance_mutation}

MCP id furlough-balance-mutations.showAlso on this path: PATCH Update a furlough balance mutation, DELETE Delete a furlough balance mutation

View as Markdown openapi.json

Returns one mutation.

Token scope: api:read:furlough
Without it: 403 insufficient-token-scope.
Permission: None. The record's own rules still apply.
Rate cost: 1 unit, read bucket.
Also: If-None-Match answers 304 when nothing changed. Never cached: private, no-store. Unknown query parameters are refused, never ignored.

Both are checked, scope first. A token never does more than its user. How access is checked

Request

Example: One mutation with the employee expanded

curl -G \
  'https://<your-url>/api/v2/furlough-balance-mutations/1' \
  --data-urlencode 'include=user' \
  -H 'Authorization: Bearer <token>' \
  -H 'Accept: application/json'

const response = await fetch('https://<your-url>/api/v2/furlough-balance-mutations/1?include=user', {
  method: 'GET',
  headers: {
    'Authorization': 'Bearer <token>',
    'Accept': 'application/json',
  },
});

use Illuminate\Support\Facades\Http;

$response = Http::withToken('<token>')
    ->acceptJson()
    ->get('https://<your-url>/api/v2/furlough-balance-mutations/1?include=user');

import requests
response = requests.request(
    'GET',
    'https://<your-url>/api/v2/furlough-balance-mutations/1?include=user',
    headers={'Authorization': 'Bearer <token>', 'Accept': 'application/json'},
)

Response

The shape of the response, with sample values.

{
  "data": {
    "id": 1,
    "user_id": 1,
    "acceptor_id": 1,
    "year": 2026,
    "type": "regular",
    "minutes": -960,
    "start": "2026-07-06T00:00:00Z",
    "end": "2026-07-07T23:59:59Z",
    "description": "Long weekend",
    "is_approved": false,
    "user": {
      "id": 1
    },
    "created_at": "2026-03-04T09:15:00Z",
    "updated_at": "2026-03-04T09:15:00Z",
    "links": {
      "self": "https://<your-url>/api/v2/work-items/1"
    }
  }
}

The summary and detail views are identical on this resource: every field is small enough for a list row. user renders as an {"id": N} reference; ?include=user expands it, and that expansion additionally requires users::read and a token scope covering the users prefix. acceptor_id has no relation to expand: look the approver up with GET /api/v2/users/{user}. As on the list operation, the furlough prefix has no read permission, so another employee's mutation answers 404, never 403, unless the caller holds furlough::view_all or furlough::manage.

Path parameters

furlough_balance_mutationintegerRequired

The FurloughBalanceMutation's numeric id.

Query parameters

Unknown parameters are refused with 400, naming the parameter.

viewstring

Which field set to render.

summarydetaildefault

Request headers

X-Request-Idstringpattern

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.

If-None-Matchstring

The ETag a read is conditional on. A match is answered 304 with no body.

Response 200

Returns a FurloughBalanceMutation in the detail view.

Headers

ETag: A strong validator of exactly this representation.
RateLimit: The IETF httpapi-ratelimit-headers form 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

idinteger

Unique identifier.

user_idintegerServer-assigned

The employee this mutation belongs to. Always the authenticated user on create and not writable.

acceptor_idinteger or nullServer-assigned

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}.

yearinteger

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.

typestring

Which leave balance this mutation moves. Regular and special leave are separate balances and never offset one another.

regularspecial

New values may be added.

minutesinteger

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.

starttimestamp (YYYY-MM-DDThh:mm:ssZ)

Start of the period this mutation covers, in UTC. Equal to end on a manual balance adjustment, which covers no period at all.

endtimestamp (YYYY-MM-DDThh:mm:ssZ)

End of the period this mutation covers, in UTC. Never before start, and equal to it on a manual balance adjustment.

descriptionstringMultiline

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.

is_approvedboolean or null

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.

userRef or UserSummary

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.