Documentation
Scheduling
scheduling.calendar
REST
ShippingPOST /api/v1/scheduling/calendarMCP tool
Livescheduling.calendarExposed on: REST API · Shop MCP server · Claude connector · Dash (in-app copilot) · Zapier. Part of the Scheduling domain.
This capability answers to an older id too
calendar.range still resolves here, on every surface, so an integration written against it keeps working. New code should use scheduling.calendar.Operating contract
The shop's calendar for a date range: every job with a scheduled_start inside it, ordered earliest-first, so 'what is on today' and 'what does tomorrow look like' are one call rather than a scan of the board.
from and to are civil dates (YYYY-MM-DD) in THE SHOP'S timezone, and to is inclusive — from and to set to the same day is that one day. Do not convert to UTC yourself; pass the day the shop would say out loud. The shop's timezone is on shop.profile.
The range may not exceed 62 days. A wider question is several calls, and answering it from one truncated page would be worse than making them.
A job with no time on it yet (a flexible booking, an unscheduled job) is NOT here at all — this reads the calendar, not the backlog. Use jobs.list for those.
Each result's id is the job_id that jobs.get, jobs.timeline, jobs.set_stage, jobs.assign and jobs.schedule take; assignee_id matches an id from jobs.staff.
TRUNCATION: total is the exact number of appointments in the range and omitted is how many are NOT in this response. Never describe a day from a response whose omitted is not 0 — call again with offset set to next_offset, or narrow the range.
Who may call it
- Permission
jobs.accessThe caller must hold Jobs 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.
Partial answers
omitted is how many matching records are not in the response, and 0 is a real answer meaning you have all of them. Continue with next_offset.
Do not summarise from a truncated response
Input
| Field | Type | Description |
|---|---|---|
| fromrequired | string | First day of the range, YYYY-MM-DD, in the shop's timezone. |
| torequired | string | Last day of the range, YYYY-MM-DD, inclusive. At most 62 days after `from`. |
| limit | integer1–200 | How many appointments to return, 1-200. Defaults to 100. Default:100 |
| offset | integermin 0 | How many to skip. Pass the previous response's next_offset to continue. Default:0 |
Output
| Field | Type | Description |
|---|---|---|
| items | object[] | — |
| items[].id | string | — |
| items[].number | number | — |
| items[].title | string | null | — |
| items[].customer_id | string | — |
| items[].vehicle_id | string | null | — |
| items[].stage | string | — |
| items[].assignee_id | string | null | — |
| items[].scheduled_start | string | null | — |
| items[].scheduled_end | string | null | — |
| items[].actual_start | string | null | — |
| items[].actual_end | string | null | — |
| items[].location_address | string | null | — |
| items[].created_at | string | — |
| total | number | — |
| omitted | number | — |
| next_offset | number | null | — |
| timezone | 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/scheduling/calendar \
-H "Authorization: Bearer $SERVICEVIN_API_KEY" \
-H "Content-Type: application/json" \
-d '{"from":"…","to":"…","limit":100,"offset":0}'const res = await fetch("https://www.servicevin.com/api/v1/scheduling/calendar", {
method: "POST",
headers: {
Authorization: `Bearer ${process.env.SERVICEVIN_API_KEY}`,
"Content-Type": "application/json",
},
body: JSON.stringify({
"from": "…",
"to": "…",
"limit": 100,
"offset": 0
}),
});
// 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/scheduling/calendar",
headers={"Authorization": f"Bearer {os.environ['SERVICEVIN_API_KEY']}"},
json={
"from": "…",
"to": "…",
"limit": 100,
"offset": 0
},
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": "scheduling.calendar",
"arguments": {
"from": "…",
"to": "…",
"limit": 100,
"offset": 0
}
}
}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 jobs.access. |
| 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. |