Documentation
Tasks
tasks.assignees
REST
ShippingPOST /api/v1/tasks/assigneesMCP tool
Livetasks.assigneesExposed on: REST API · Shop MCP server · Claude connector · Dash (in-app copilot) · Zapier. Part of the Tasks domain.
Operating contract
Who in this shop can actually be handed work: active members whose role grants inbox access, or full admin. Call it before tasks.create, tasks.update with staff_id, or comms.update_conversation with staff_id — the user_id values here are the only ones those three accept.
IT IS NOT THE STAFF LIST. A shop's roster includes bench technicians and installers who never open the inbox, and parking a to-do on one of them is an assignment that appears to work and silently never happens: the Tasks tab is not in their nav, the deep link bounces them, and the database refuses them the row. This is the roster filtered to people who can do something about it.
The same list governs conversation assignment, which is why one capability serves both domains rather than each publishing its own copy of a roster that must not disagree.
No arguments and no page: a shop's inbox roster is a handful of people. staff.* (the team domain) is where pay, roles and the full member list live — this answers one question and does not duplicate that.
Who may call it
- Permission
inbox.accessThe caller must hold Inbox 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
This capability takes no arguments.
Output
| Field | Type | Description |
|---|---|---|
| items | object[] | — |
| items[].user_id | string | — |
| items[].name | 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/tasks/assignees \
-H "Authorization: Bearer $SERVICEVIN_API_KEY" \
-H "Content-Type: application/json" \
-d '{}'const res = await fetch("https://www.servicevin.com/api/v1/tasks/assignees", {
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/tasks/assignees",
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": "tasks.assignees",
"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 inbox.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. |