Skip to main content
Documentation
Service VIN developer & AI platformGetting startedAuthenticationPaginationIdempotencyRate limitsErrorsWebhooks & signature verificationConnecting ClaudeRecipesMCP servers & the Claude connectorREST resource referenceCapability indexCustomers capabilitiesVehicles capabilitiesLeads capabilitiesWarranties capabilitiesQuotes capabilitiesInvoices capabilitiesPayments capabilitiesServices capabilitiesJobs capabilitiesCalendar capabilitiesScheduling capabilitiesStaff capabilitiesInventory capabilitiesComms capabilitiesTasks capabilitiesShop capabilitiesDocuments capabilitiesKnowledge capabilitiesReports capabilitiesBooking capabilitiesForms capabilitiesMarketing capabilitiesReviews capabilitiesAutomations capabilitiesIntegrations capabilitiesChangelogSearch

Guide

Getting started

Mint a key, make your first authenticated call, and understand what a capability is before you call one.

Service VIN publishes one capability registry — a typed description of every operation the product can perform — and every surface reads it. The REST API, the two MCP servers, the Claude connector and the in-app copilot are all generated from it, which is why this reference cannot drift from the software: a capability added for a dashboard feature appears here on merge.

Three minutes

  1. 1Open Settings → API keys in your dashboard and click Create key. You need the owner or manager role.
  2. 2Copy the key immediately. It is shown once — only a one-way hash is stored, so there is no way to reveal it again. Lost it? Revoke and mint another.
  3. 3Put it in your shell and call /me. A 200 naming your shop means you are connected.
Your first request
export SERVICEVIN_API_KEY=svk_live_…

curl $SERVICEVIN_ORIGIN/api/v1/me \
  -H "Authorization: Bearer $SERVICEVIN_API_KEY"

What a capability is

A capability is one operation, described once. Its id — jobs.set_stage, customers.find_by_contact — is as permanent as a REST path: an integration, a saved Claude prompt and a Zap all hold it, so it is never renamed. A rename goes through a deprecation alias, and the old id keeps resolving.

Every capability declares what it DOES rather than leaving you to infer it: whether it writes, whether it can reach a customer, which permission it needs, which plan it needs, how it behaves on a retry, and which budget it is counted against. Those declarations are the badges on each capability's page, and they are the same fields the API's scope check and the MCP tool filter read.

Nothing here deletes anything or moves money

No capability charges, refunds, pays out, credits, or does anything a write-back cannot undo — not over REST, not over MCP, not through the connector, not in the copilot. A cancel sets a status; a refund stays a human at a screen. This is a line, not a phase-two item, and check:capabilities refuses a registry entry that declares either.

Which surface to build on

  • REST — you are writing code that syncs, imports or reacts. Bearer key, JSON envelopes, cursor pagination, signed webhooks.
  • MCP — you are pointing an AI at the shop. Same capabilities, same gates, presented as tools with an operating contract each.
  • The Claude connector — the shop owner clicks Connect in Claude and consents; you write nothing at all.