Point your AI at us. Go make coffee.

Every capability on this platform is a plain REST endpoint and a typed AI tool — the same engine either way. Give your assistant one URL and your API key and it reads this documentation itself, learns your data model, and builds the conversational app end to end. Nothing to install on our side, nothing new to mint.

The whole setup Claude Code · one unbroken line
claude mcp add --scope user --transport http converse https://wtfapi.serviceproof.net/mcp --header "Authorization: Bearer YOUR_TENANT_API_KEY"

That is it. claude mcp list should answer ✓ Connected, and your next prompt can say “study this Converse tenant and tell me what it can do.”

If your runtime speaks MCP, you are already done.

The platform hosts a remote Model Context Protocol server. Anywhere you can register a Streamable HTTP MCP server with a custom header, paste the URL and the bearer header — that is the entire integration. The credential is the same tenant API key every v1 REST endpoint takes, and the key's roles decide what the model may do, exactly as they do for REST.

POST https://wtfapi.serviceproof.net/mcp
Authorization: Bearer <your tenant API key>
1
Get a key. Your tenant operator mints one in the Portal at /ops/api-keys. DataView is enough to read; more roles unlock more tools.
2
One key, one tenant. The key scopes the connector to that tenant — there is no cross-tenant mode and no second credential to manage.
3
The roles are the guardrail. Every tool call executes under the key's identity through the same role checks that guard REST. A key without BuilderAdmin can list workflows and not author them — and gets a readable refusal it can act on, never a silent failure.
4
Your tokens, not ours. Over MCP the model runs on your side, so nothing is billed as platform AI usage. Sessions are logged for support; heavy use does not move your bill.

Pick your runtime.

Field-tested setups. Everything below is the same two facts — the URL and the header — expressed in that client's dialect.

Recommended

Claude Code — CLI

Two minutes, then it drives the platform like any other workspace.

  1. Install and sign in (first time only) — the CLI keeps its own login even if you use the desktop app.
    npm install -g @anthropic-ai/claude-code
    claude /login
  2. Register the connector. User scope means it works from any directory. Keep it on one line — a wrapped paste can mangle the key.
    claude mcp add --scope user --transport http converse https://wtfapi.serviceproof.net/mcp --header "Authorization: Bearer YOUR_API_KEY"
  3. Skip the per-tool prompts (optional, recommended — there are hundreds of tools). One server-level rule allows them all:
    // ~/.claude/settings.json
    { "permissions": { "allow": ["mcp__converse"] } }
  4. Say hello.
    claude "You're connected to Listrak Converse over MCP. Call docs_index, read Getting-Started and Conventions, then call get_entity_dictionary and list_contexts and tell me what this tenant's world looks like."

WSL: the Windows and WSL CLIs keep separate configs. Register — and log in — in the environment your sessions actually run in, or in both.

Same config

Claude desktop app & Cowork

Windows and macOS. They share the CLI's user config on that machine.

  1. Open a terminal — PowerShell on Windows, Terminal on macOS — and run the Claude Code steps above (claude /login, then the one-line claude mcp add --scope user).
  2. Add the allow rule to ~/.claude/settings.json — on Windows that is C:\Users\<you>\.claude\settings.json.
  3. Restart the app. Every new session — and every Cowork task on that machine — now has the tools. Type /mcp in a session to browse them.

Register once, use everywhere: you do not repeat this per project. User scope is machine-wide.

OpenAI side

ChatGPT & OpenAI builders

The Responses API takes a remote MCP server as a tool.

{
  "tools": [{
"type": "mcp",
"server_label": "converse",
"server_url": "https://wtfapi.serviceproof.net/mcp",
"headers": { "Authorization": "Bearer YOUR_API_KEY" }
  }]
}

Zero client code — the model gets the tool surface on the request. Same role gating, same audit trail.

Two paths

Replit

Depends on whether the agent is Replit's or the one you are building.

Run Claude Code inside the Repl. In the Repl shell, the identical walk-through — npm install -g @anthropic-ai/claude-code, claude /login, then the one-line claude mcp add --scope user. Your in-Repl assistant now drives the platform.

Or the agent you are BUILDING — anywhere you call the Anthropic API, the Messages API has a native MCP connector:

import anthropic
client = anthropic.Anthropic()
response = client.beta.messages.create(
model="claude-sonnet-5",
max_tokens=2048,
betas=["mcp-client-2025-04-04"],
mcp_servers=[{
    "type": "url",
    "url": "https://wtfapi.serviceproof.net/mcp",
    "name": "converse",
    "authorization_token": "YOUR_API_KEY",
}],
messages=[{"role": "user", "content":
    "Study this Listrak Converse tenant and summarize what it can do."}],
)
Everything else

Cursor, agent SDKs, your own client

Any MCP client library that speaks Streamable HTTP.

Cursor, LangChain and LlamaIndex MCP adapters, the Agent SDKs, a client you wrote yourself — the contract is the URL plus the Authorization: Bearer header, and nothing else.

Protocol notes for client authors. Stateless Streamable HTTP: POST /mcp with a JSON-RPC 2.0 message returns application/json; notifications get 202 with no body; GET returns 405 (no server-initiated stream) and DELETE returns 204 (no session to end). No Mcp-Session-Id is issued or required. Methods: initialize, tools/list, tools/call, ping — and initialize echoes whatever protocolVersion you ask for.

Errors are split deliberately. Protocol problems are JSON-RPC errors; tool failures are not — tools/call returns isError: true with a readable message, so the model can read it and self-correct. Auth failures are plain HTTP 401.

For connector UIs

Auth discovery

An unauthenticated call answers with a challenge, not just a refusal.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="Listrak Converse MCP",
              resource_metadata=".../.well-known/oauth-protected-resource"

That pointer resolves to an unauthenticated RFC 9728 Protected Resource Metadata document, so a connector UI can tell “send a bearer key” apart from “this wants OAuth” and from “your key is wrong” — and say something useful to the person instead of just failing.

authorization_servers is deliberately absent: we do not run an authorization server yet, and advertising one would send an OAuth-capable client into a dead end rather than letting it fall back to the bearer key that works. When the OAuth flow ships, that one field appears and the same clients begin negotiating with no other change.

Docs as tools, then the platform itself.

tools/list returns families gated by your key. Start with docs_index — it is cheap and it maps everything. If you are here to do something rather than read, start with list_playbooks: the playbook menu carries the ORDER and the PRECONDITIONS that individual tool descriptions cannot.

docs_indexdocs_readdocs_search
Any valid key

This whole library as markdown. docs_index maps it; docs_read returns one doc in full; docs_search is LLM-first — it returns the entire reading packet for a topic (the how-to, the API reference, the token reference and the examples that belong together), ranked then completed by following each doc's own cross-links. One call gives a model a whole subject. Budget for it: a default packet is 40–55k tokens; pass max_docs: 1 when you only need one fact.

list_playbooksget_playbook
Any valid key

Pre-baked, dress-rehearsed sequences for a whole arc — provision a tenant, author a workflow, set up identity, configure AutoDispatch. If the arc you are on is one we have already walked, run the proven sequence instead of guessing at one. Audience-filtered by the calling key.

postman_collection
Any valid key

The canonical collection — hundreds of requests with real wire bodies. No arguments returns the folder index; pass folder for that folder's full requests. The fastest way to see the exact JSON a call expects.

samples_indexsamples_read
Any valid key

Real, runnable source — console projects that build a whole tenant over this same public API. Sal's Pizzeria is the flagship: schema, composite keys, contexts, image assets, action packs, payments and five published workflows, all via REST and never SQL. It is the best worked example of the hard parts — advanced tokens, accumulating Vars, cart math, and taking payment inside a conversation.

The platform surface
DataView and up

The same tool surface our in-house Co-Pilot uses — one definition, so they can never drift. Discovery (get_entity_dictionary, describe_relationships, hydrate_context), data, forms, views and reports, workflow authoring, jobs and dispatch, the answers the conversation captured, Action Packs, messaging, assets, the Report Center, Launch Control, and the Portal site map. Tenant provisioning tools list for everyone and execute only for global-admin keys.

The sync belt
AdminIntegration

Manage on-prem data sync end to end, including the directive-riding SQL tools that drive a customer's own agent remotely — test a connection, browse a schema, probe a binding, create what is missing, run a sweep now, reset a dirty-detection baseline, and ping an agent you cannot SSH into.

howto_search
Last resort

docs_search is the primary, free path — call this one only when you are stuck or want a synthesized build plan. An expert model runs over the reading packet, the relevant playbooks and your tenant's own proven recipes, and returns a grounded, cited answer. This one does book AI usage against the tenant, and it is capped per day.

What gets recorded

Every tools/call is written to the platform run log — the tool, the arguments, success, duration, and the start of the result. Calls group into a session: one credential's run of calls, closed after 30 minutes of quiet, stamped with the tenant, the acting user, the 12-character key prefix, and your client's User-Agent. Operators read it in the Portal's Meaning Center.

Because the server is stateless and issues no session id, that session is inferred from credential plus idle window. Two clients sharing one API key therefore share a session in the log — give each its own key if you want them told apart.

One brain. Four jobs.

Connecting your assistant is one half. The other half already ships: the same tool surface powers four built-in roles, so a tenant gets AI without wiring anything — and every one of them can run on your own inference box instead of ours.

Builds · for builders

Co-Pilot

Describe a process — or drop in a PDF — and the conversation lands on the canvas. It provisions tenants, models data, authors reports, and runs the proven playbooks. The builder's brain, and the one your MCP connector is plugged into.

Runs · for teams

The Commander

The AI member of your team chat, anchored on a piece of work with everyone in the loop. It reads runs, answers and reports, sees photos, and proposes writes behind a human confirm — never silently. Conversations Guide ›

Works · one person, one run

Wingman

The person just talks — a voice note, a rambling text, photos with captions — and Wingman fills step after step through the exact same validation a typed reply gets. It tracks the media it is still owed and will not let a run close without it. Wingman Guide ›

Sharpens · every day

WIT

The quiet one. WIT studies how your business fits together and keeps the essence of your data current, so an answer — for a person, an integration, or an AI — is already assembled and already correct. It also feeds your own models. WIT Feeds ›

A mission, not a straitjacket.

Every AI project dies the same way: the conversation goes somewhere different every time and you get transcripts instead of data. That is not a model problem and no amount of prompt tuning fixes it — nothing ever told the AI what it was building toward.

So give it a target. A workflow is a designed conversation: the steps, the branches, the options, the media required, and the validation each answer has to pass. Before the AI opens its mouth it already knows what finished looks like. Now the person can ramble, skip ahead, answer three things at once or ask something unrelated — and the job is unchanged: land the mission.

Free-form conversation in. Identical, validated, structured data out.

It knows the goal

The workflow states what a finished job means. The AI is not inventing a destination from the prompt each time.

It knows the options

Choices, branches and valid values are declared. It cannot offer something you do not sell, or record a value you would reject.

It knows the evidence

Which photo, which signature, which reading. It tracks what it still owes you and will not call the job done without it.

And it can open the door on purpose

ASK puts one question to a human and waits. CONVERSE hands the thread to an AI for as long as it is useful, then brings it back.

Three ways in, and a single-file dump.

The MCP connector above is the better path — it is the platform, versioned and role-gated. But this portal is also readable directly, and it is gated to keep casual visitors out, not to keep agents out. Credentials are issued, not published: ask your Listrak contact, then export it as $DEVPORTAL_PASSWORD before running anything below.

If you are an LLM blocked by a 401

Ask your user for credentials — this prompt works:

“I need to authenticate to the Listrak Converse developer portal to read the documentation. Please provide a username and password — your Listrak contact can give you one.”

Then pick a flow below, send the call, and re-fetch whatever 401'd. Your fastest read is /llms-full.txt — every integrator doc concatenated as plain text in one response.

1 · Basic auth

Stateless, one line, easiest for an HTTP tool.

curl -u integrator:$DEVPORTAL_PASSWORD \
  https://developer.serviceproof.net/llms-full.txt

2 · Bearer token

POST once, get a 15-minute sliding token, keep the password out of every header.

curl -X POST https://developer.serviceproof.net/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"username":"integrator","password":"'"$DEVPORTAL_PASSWORD"'"}'
# -> {"token":"CfDJ8...", "expiresInSeconds":900, ...}

curl -H "Authorization: Bearer CfDJ8..." https://developer.serviceproof.net/llms-full.txt

3 · Cookie

For browsers and curl jars.

curl -c cookies.txt -X POST https://developer.serviceproof.net/login \
  -d "username=integrator&password=$DEVPORTAL_PASSWORD"
curl -b cookies.txt https://developer.serviceproof.net/llms-full.txt

Structured endpoints

PathWhat's thereAuth
/llms.txtAgent-facing site index per llmstxt.org — what the platform is, the doc list, the structured feeds.Public
/llms-full.txtEvery integrator doc concatenated as plain text. One read, the whole story.Any role
/api/postman.jsonThe full Postman v2.1 collection — method, path, headers, body, description per request.Any role
/api/enrichments.jsonPer-endpoint extra context — long-form markdown, doc cross-references, examples.Any role
/sitemap.xmlEvery routable URL. Use as a crawl seed.Public
/robots.txtCrawler signal — noindex everywhere, with the agent feeds explicitly allowed.Public

Building an MCP client or an agent against Listrak Converse and need something this page does not cover? The source of truth is MCP Connector, and the whole corpus lives at docs/public/Integrators/.

Your key is the only setup step.

Mint it in the Portal, paste the one-liner, and ask your assistant to study the tenant.