Skip to main content
Documentation

Forms

forms.funnel

Show where visitors give up on one lead form, step by step
Read-onlyRead budget

REST

Shipping
POST /api/v1/forms/funnel

MCP tool

Live
forms.funnel

Exposed on: REST API · Shop MCP server · Claude connector · Dash (in-app copilot) · Zapier. Part of the Forms domain.

Operating contract

THE READ NOTHING ELSE GIVES YOU: how many people saw each step of a form and how many got past it. A submission count says who finished; this says where everybody else stopped.

worst: true marks the step losing the most people. That is the one to change, and it is usually not the one a shop would guess — a question that feels reasonable to the person who wrote it often is not to somebody on a phone at a traffic light.

rate is completions ÷ views and is NULL below a handful of views, deliberately: a step seen four times tells you nothing, and a 25% rate computed from it is noise dressed as a finding. Never report a rate that came back null as zero.

dropped is the raw count of people who saw a step and did not get past it, and it is often the more persuasive number — 'forty people stopped at the vehicle question' lands where '38% completion' does not.

entered is views on the first step — the honest denominator for 'how many people started' — and finished is completions on the contact step, which is submissions inside this window. Those two are the headline; the per-step rows say where the difference went.

enough_data: false means the form has too little traffic in this window to read percentages from. Say that rather than reporting the rates: the panel itself refuses to draw them.

removed_steps counts traffic on steps that are no longer in the form. It is history, not a stage, and it is separated so a deleted step cannot look like a live problem.

COUNTERS ARE DAILY AND BUCKETED IN UTC, so a day is counted in exactly one window rather than twice or not at all. That means the edges of a 7-day window may not line up with the shop's own calendar day; for a trend over weeks it does not matter, and for a single day it does.

Pick a window with range: 7d, 30d or 90d. A short window on a quiet form gives you mostly nulls, which is honest — say the form has too little traffic to judge rather than reading noise.

Who may call it

Permission
leads.accessThe caller must hold Leads 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

FieldTypeDescription
form_idrequiredstringuuid

The form to analyse, as returned by forms.list.

rangestring

The window to measure over. Defaults to 30d.

Default: "30d"One of: 7d, 30d, 90d

Output

FieldTypeDescription
form_idstring

rangestring

stepsobject[]

steps[].step_idstring

steps[].labelstring

steps[].kindstring

steps[].viewsnumber

steps[].completionsnumber

steps[].droppednumber

steps[].ratenumber | null

steps[].worstboolean

enterednumber

finishednumber

enough_databoolean

removed_stepsobject

removed_steps.stepsnumber

removed_steps.viewsnumber

removed_steps.completionsnumber

Examples

Built from this capability's own schema — required fields and the ones carrying a default, and nothing invented. Paste one and it validates.

curl
export SERVICEVIN_API_KEY=svk_live_…

curl -X POST https://www.servicevin.com/api/v1/forms/funnel \
  -H "Authorization: Bearer $SERVICEVIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"form_id":"9b2f1c6e-4a77-4d2b-9f31-0f1c9a8e5d20","range":"30d"}'

TypeScript (fetch)
const res = await fetch("https://www.servicevin.com/api/v1/forms/funnel", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.SERVICEVIN_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    "form_id": "9b2f1c6e-4a77-4d2b-9f31-0f1c9a8e5d20",
    "range": "30d"
  }),
});

// 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;

Python (requests)
import os, requests

res = requests.post(
    "https://www.servicevin.com/api/v1/forms/funnel",
    headers={"Authorization": f"Bearer {os.environ['SERVICEVIN_API_KEY']}"},
    json={
    "form_id": "9b2f1c6e-4a77-4d2b-9f31-0f1c9a8e5d20",
    "range": "30d"
},
    timeout=30,
)
payload = res.json()
if not res.ok:
    raise RuntimeError(payload["error"]["code"])
data = payload["data"]

MCP tools/call — https://www.servicevin.com/api/mcp
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "forms.funnel",
    "arguments": {
      "form_id": "9b2f1c6e-4a77-4d2b-9f31-0f1c9a8e5d20",
      "range": "30d"
    }
  }
}

Refusals

The four gates run in this order on every surface, and the order is not arbitrary — see Authentication.

StatusCodeWhen
404not_foundThe id is unknown, or the feature is not enabled for this account. Deliberately the same answer for both.
403forbiddenThis login does not hold leads.access.
422validation_errorAn argument was wrong. The message names the field.
429rate_limitedToo many read calls. Back off and retry.
500internal_errorSomething failed on our side. Nothing was changed.