Skip to main content
Documentation

Staff

staff.time_off_requests

List the time-off requests waiting on a staff manager's answer
Read-onlyRead budget

REST

Shipping
POST /api/v1/staff/time_off_requests

MCP tool

Live
staff.time_off_requests

Exposed 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

FieldTypeDescription
include_decidedboolean

True also returns the most recently approved or declined requests, for context.

Output

FieldTypeDescription
readyboolean

pending_countnumber

pendingobject[]

pending[].idstring

pending[].staff_idstring

pending[].namestring

pending[].kindstring

pending[].starts_onstring

pending[].ends_onstring

pending[].notestring | null

pending[].requested_atstring

pending[].conflictsobject[]

pending[].conflicts[].job_idstring

pending[].conflicts[].job_numbernumber | null

pending[].conflicts[].titlestring | null

pending[].conflicts[].customer_namestring | null

pending[].conflicts[].scheduled_startstring | null

decidedobject[]

decided[].idstring

decided[].namestring

decided[].kindstring

decided[].starts_onstring

decided[].ends_onstring

decided[].statusstring

Examples

Built from this capability's own schema — required fields and the ones carrying a default, and nothing invented. Paste one and it validates.

curl
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 '{}'

TypeScript (fetch)
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;

Python (requests)
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"]

MCP tools/call — https://www.servicevin.com/api/mcp
{
  "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.

StatusCodeWhen
404not_foundThe id is unknown, or the feature is not enabled for this account. Deliberately the same answer for both.
403forbiddenThis login does not hold shop.manage.
422validation_errorAn argument was wrong. The message names the field.
429rate_limitedToo many read calls. Back off and retry.
500internal_errorSomething failed on our side. Nothing was changed.