Documentation
Staff
staff.time_off_requests
REST
ShippingPOST /api/v1/staff/time_off_requestsMCP tool
Livestaff.time_off_requestsExposed on: REST API · Shop MCP server · Claude connector · Dash (in-app copilot) · Zapier. Part of the Staff domain.
Operating contract
THE QUEUE SOMEBODY HAS TO ANSWER, soonest-starting first — and every pending row carries the jobs ALREADY ASSIGNED to that person inside the window they are asking for.
THE CONFLICTS ARE THE POINT. Approving a week off for somebody who is booked onto four cars that week does not cancel those cars; it leaves them assigned to a person who is not there, and nothing downstream notices. Read conflicts before saying anything encouraging about a request.
decided is recent history for context — what has already been approved or declined. Do not report a decided request as though it were waiting.
APPROVING AND DECLINING ARE NOT HERE. It is a person's holiday and a manager's answer, and on approval the shop is committing to work a week short. Reading the queue and its conflicts is the half a machine is good at.
ready: false means the time-off migration is not applied to this shop's database — there is no queue to read, and an empty list is not evidence that nobody has asked.
The pending queue and a dozen decided rows are returned in full, so nothing is truncated.
Who may call it
- Permission
shop.manageThe caller must hold shop.manage at the ACT level. A read-only dashboard grant on the same section is refused.- Plan
- Every planNo plan gate. Available on every Service VIN plan.
- Retries
naturalNaturally idempotent — running it twice leaves the same world as running it once. A retrying integration needs no key.- Rate class
readCounted against the read budget — the widest of the four.
Input
| Field | Type | Description |
|---|---|---|
| include_decided | boolean | True also returns the most recently approved or declined requests, for context. |
Output
| Field | Type | Description |
|---|---|---|
| ready | boolean | — |
| pending_count | number | — |
| pending | object[] | — |
| pending[].id | string | — |
| pending[].staff_id | string | — |
| pending[].name | string | — |
| pending[].kind | string | — |
| pending[].starts_on | string | — |
| pending[].ends_on | string | — |
| pending[].note | string | null | — |
| pending[].requested_at | string | — |
| pending[].conflicts | object[] | — |
| pending[].conflicts[].job_id | string | — |
| pending[].conflicts[].job_number | number | null | — |
| pending[].conflicts[].title | string | null | — |
| pending[].conflicts[].customer_name | string | null | — |
| pending[].conflicts[].scheduled_start | string | null | — |
| decided | object[] | — |
| decided[].id | string | — |
| decided[].name | string | — |
| decided[].kind | string | — |
| decided[].starts_on | string | — |
| decided[].ends_on | string | — |
| decided[].status | string | — |
Examples
Built from this capability's own schema — required fields and the ones carrying a default, and nothing invented. Paste one and it validates.
export SERVICEVIN_API_KEY=svk_live_…
curl -X POST https://www.servicevin.com/api/v1/staff/time_off_requests \
-H "Authorization: Bearer $SERVICEVIN_API_KEY" \
-H "Content-Type: application/json" \
-d '{}'const res = await fetch("https://www.servicevin.com/api/v1/staff/time_off_requests", {
method: "POST",
headers: {
Authorization: `Bearer ${process.env.SERVICEVIN_API_KEY}`,
"Content-Type": "application/json",
},
body: JSON.stringify({}),
});
// Success and failure are both envelopes. Switch on error.code, never
// on error.message — the codes are stable, the messages are for people.
const payload = await res.json();
if (!res.ok) throw new Error(payload.error.code);
const data = payload.data;import os, requests
res = requests.post(
"https://www.servicevin.com/api/v1/staff/time_off_requests",
headers={"Authorization": f"Bearer {os.environ['SERVICEVIN_API_KEY']}"},
json={},
timeout=30,
)
payload = res.json()
if not res.ok:
raise RuntimeError(payload["error"]["code"])
data = payload["data"]{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "staff.time_off_requests",
"arguments": {}
}
}Refusals
The four gates run in this order on every surface, and the order is not arbitrary — see Authentication.
| Status | Code | When |
|---|---|---|
| 404 | not_found | The id is unknown, or the feature is not enabled for this account. Deliberately the same answer for both. |
| 403 | forbidden | This login does not hold shop.manage. |
| 422 | validation_error | An argument was wrong. The message names the field. |
| 429 | rate_limited | Too many read calls. Back off and retry. |
| 500 | internal_error | Something failed on our side. Nothing was changed. |