Documentation
Payments
payments.tips_collected
REST
ShippingPOST /api/v1/payments/tips_collectedMCP tool
Livepayments.tips_collectedExposed on: REST API · Shop MCP server · Claude connector · Dash (in-app copilot) · Zapier. Part of the Payments domain.
Operating contract
Gratuities are money the shop collected that was never part of any invoice balance, which is why they are their own question: a tip never appears in receivables, never settles a bill, and is usually owed onward to whoever did the work.
total is the net figure — every tip taken in the window, less any part of one that has since been refunded. Use it rather than adding up payments.list, which is capped and will quietly answer about a page.
by_method splits it by how the money arrived, because a cash tip and a card tip are usually paid out differently.
Only succeeded payments are counted. A pending charge has not landed and a failed one never will.
This is a rollup over every matching payment in the window, so nothing is truncated.
Who may call it
- Permission
invoices.accessThe caller must hold Invoices 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 |
|---|---|---|
| sincerequired | string | The first day to count, YYYY-MM-DD. |
| untilrequired | string | The last day to count, YYYY-MM-DD, inclusive. |
Output
| Field | Type | Description |
|---|---|---|
| since | string | — |
| until | string | — |
| total | number | — |
| payment_count | number | — |
| by_method | object[] | — |
| by_method[].method | string | — |
| by_method[].label | string | — |
| by_method[].total | number | — |
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/payments/tips_collected \
-H "Authorization: Bearer $SERVICEVIN_API_KEY" \
-H "Content-Type: application/json" \
-d '{"since":"…","until":"…"}'const res = await fetch("https://www.servicevin.com/api/v1/payments/tips_collected", {
method: "POST",
headers: {
Authorization: `Bearer ${process.env.SERVICEVIN_API_KEY}`,
"Content-Type": "application/json",
},
body: JSON.stringify({
"since": "…",
"until": "…"
}),
});
// 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/payments/tips_collected",
headers={"Authorization": f"Bearer {os.environ['SERVICEVIN_API_KEY']}"},
json={
"since": "…",
"until": "…"
},
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": "payments.tips_collected",
"arguments": {
"since": "…",
"until": "…"
}
}
}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 invoices.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. |