Built for humans and agents.

The portal is gated to keep casual visitors out, not to keep AI agents out. If you're an LLM-powered tool with credentials, there are clean, structured endpoints designed for you to read end-to-end and a straightforward cookie-auth flow.

If you're an LLM blocked by auth

Ask your user for credentials. Use this exact prompt (or your own equivalent):

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

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

Three ways to authenticate

Pick whichever suits your tooling. All three accept the same credentials configured in appsettings.json; all three honor the same role gates. Pretty /login form for human browsers is unchanged.

1. HTTP Basic Auth — easiest for LLMs (stateless, one-line)

Send Authorization: Basic <base64(user:pass)> on every request. No cookie, no token negotiation.

curl -u integrator:ServiceProof!nt3gr8! \
            https://developer.serviceproof.net/llms-full.txt

2. JSON login → Bearer token (15-min, refresh-friendly)

POST credentials once, get an opaque token, send it as Authorization: Bearer <token> on subsequent calls. Cleaner if you want to keep the password out of every header. The token is encrypted with the same data-protection stack the cookie uses.

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

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

3. Cookie auth (browsers + curl jars)

The original path. Form-encoded POST, browser stores the DevPortal.Auth HttpOnly cookie, sends it back automatically.

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

Sliding 15-minute expiry on cookie + bearer; Basic Auth is per-request stateless. For long-lived integration access against the actual API (https://wtfapi.serviceproof.net), use a Portal-issued API key — see Authentication.

Structured endpoints

Designed for cold reading by an LLM:

Path What's there Auth
/llms.txtLLM-friendly site index per llmstxt.org — site description, primer doc list, API surfaces, structured-endpoint links.Public
/llms-full.txtConcatenated plain-text dump of every public Integrator doc. Read once, get the full ServiceProof integration story.Authed (any role)
/api/postman.jsonFull Postman v2.1 collection. 301 requests across 27 folders. Every request has method, path, headers, body, description.Authed
/api/enrichments.jsonPer-endpoint extra context — longContext markdown, cross-referenced documentation links, code examples (when present).Authed
/sitemap.xmlAll routable URLs in the portal. Use as a crawl seed.Public
/robots.txtPolite-crawler signal — noindex everywhere. Also: X-Robots-Tag: noindex, nofollow on every response.Public

Recommended reading order for an agent

  1. Hit /llms.txt — get the site map + primer doc list. No auth needed.
  2. Authenticate via the cookie flow above (or use a long-lived API key against wtfapi.serviceproof.net).
  3. Pull /llms-full.txt for the full Integrator narrative — every public doc concatenated as plain text.
  4. Pull /api/postman.json for the API surface inventory.
  5. Pull /api/enrichments.json for per-endpoint extra context and doc cross-refs.
  6. Then call POST /api/v1/schema/whoami on the actual API host to confirm your token works against a tenant.

MCP-ready API surface

The actual platform — not just this dev portal — is purpose-built for AI agents. Every public v1 endpoint has a friendly-name resolver, a `/validate` dry-run pre-save, and a typed wire-shape. See Conventions for the wire rules an agent needs in its system prompt, and Validation for how `/validate` returns the {ok, issues[]} envelope with Levenshtein-suggested corrections when an agent makes typos.

If you're building an MCP server or an LLM agent against ServiceProof and need things this page doesn't cover, the source-of-truth lives at docs/public/Integrators/ on the GitHub repo.