Documentation
Warranties
warranties.expiry_summary
REST
ShippingPOST /api/v1/warranties/expiry_summaryMCP tool
Livewarranties.expiry_summaryExposed on: REST API · Shop MCP server · Claude connector · Dash (in-app copilot) · Zapier. Part of the Warranties domain.
Operating contract
THE READ FOR 'WHAT IS ABOUT TO LAPSE'. Five counts over the WHOLE registry — not a page of it — so a number here is the real number and can be said out loud.
Use this rather than counting warranties.list. That read pages, and a count from a truncated page understates exactly the thing a shop is trying to act on.
expiring is anything lapsing inside the next 60 days, measured against the shop's own calendar day. That window is what makes the count actionable: a customer can still be contacted and re-sold inside it.
closed is warranties that were voided or claimed out. They are not expiries and should not be added to them.
Pass customer_id to answer the same five questions about one person, which is the read behind 'is this customer still covered for anything'.
This counts every matching warranty rather than paging, so nothing is truncated.
Who may call it
- Permission
customers.accessThe caller must hold Customers 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 |
|---|---|---|
| customer_id | stringuuid | Narrow to one customer, as returned by customers.list or customers.get. |
Output
| Field | Type | Description |
|---|---|---|
| all | number | — |
| active | number | — |
| expiring | number | — |
| expired | number | — |
| closed | number | — |
| expiring_soon_days | 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/warranties/expiry_summary \
-H "Authorization: Bearer $SERVICEVIN_API_KEY" \
-H "Content-Type: application/json" \
-d '{}'const res = await fetch("https://www.servicevin.com/api/v1/warranties/expiry_summary", {
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/warranties/expiry_summary",
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": "warranties.expiry_summary",
"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 customers.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. |