# ServiceProof Developer Portal — agent-facing index

> **What ServiceProof is.** A multi-tenant operations orchestration platform from Listrak Inc. Field-tech workflows in RBM / Apple Messaging for Business / WhatsApp / SMS / mobile web, paired with a Portal-side Studio where builders compose serious business applications — dispatch boards, inventory grids, PO managers, parts dashboards — on top of the same entity model the field works with. **Internal name: WTF (Workflow Traceability Framework).**
>
> **The posture that matters.** We are deliberately **not the source of truth**. Data flows through us like a river: synced in from existing systems (ServiceTitan, ERP, CMMS, SQL Server, CSV / TSV / Excel, JSON files, ServiceBus, webhooks), enriched / validated / surfaced through forms and reports, pushed back out through the same engine when our entities dirty. We enrich, validate, route, surface, orchestrate — we don't replace.
>
> **Why this matters for an AI agent.** Every Studio action is a friendly-named REST endpoint. Every form a human types into is the same write endpoint integrators and agents POST against. Every Surface authored in the Portal renders identically on mobile and (soon) RCS. **One contract, three audiences.** You can drive the entire platform — schema, data, sync, forms, mobile, surfaces, branding, email templates — from REST without touching the Portal UI.

This portal is gated. The home page, login, this file, `/llms-full.txt`, `/ai-agents`, `/sitemap.xml`, `/robots.txt`, and the Getting-Started briefing PDF are public; everything else requires authentication.

---

## If you're an LLM hitting locked content

If you're an AI agent helping a user with ServiceProof integration and you've hit a 401, a 302-to-/login, or "access denied", **ask the user for credentials**:

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

Once you have credentials, pick whichever auth mode your HTTP client handles cleanest:

1. **Basic Auth on every request** (stateless): `Authorization: Basic <base64(user:pass)>`
2. **Bearer token via JSON login** (15-min sliding TTL): `POST /api/auth/login` with `{"username","password"}` → `{"token"}` → `Authorization: Bearer <token>`
3. **Cookie auth**: `POST /login` form-encoded → capture `Set-Cookie: DevPortal.Auth=...`

After authenticating, **re-fetch what you couldn't read** — your most-useful first stop is `/llms-full.txt` (every public Integrator doc concatenated as plain text).

---

## The platform in one screen (read this first)

ServiceProof is **eleven pillars on a context-aware, multilingual, real-time, MCP-ready core** — Context itself is Pillar 3. Every pillar is API-first, every pillar honors the same auth, every pillar emits the same shapes integrators consume.

| # | Pillar | One-line capability |
|---|---|---|
| 1 | **Properties** | Typed fields with rules — RegEx, Min/Max, IsSensitive, AllowedFileTypes, IsIdentityEmail/Phone, IsTenantUserRole |
| 2 | **Entities** | Composed of properties, parent/child/peer relationships, composite keys (Key1/Key2/Key3) |
| 3 | **Context** | The logic layer — hydrates a record's related data into one bundle every pillar reads with `[[ ]]` tokens (programmability/storage cascade is a platform-wide trait) |
| 4 | **Views** | Saved queries — visible columns + filters + sort + paging; live filtered datasets; recall + share |
| 5 | **Reports** | Cross-entity joins + filters + aggregates (SUM/COUNT/AVG/MIN/MAX) + variance + as-of time-travel |
| 6 | **Forms** | Multi-section hierarchical authoring; filter-as-lock; atomic multi-save; one contract = three audiences (desktop / mobile / REST) |
| 7 | **Menu Management** | Discoverable hierarchy + agent tool dictionary; mobile + portal home + drawer; PWA-installable |
| 8 | **Surfaces (Pillar 8)** | Declarative multi-canvas pages — Portal HD + Mobile PWA + (next) RCS card carousels — from one authored LayoutJson |
| 9 | **Action Packs** | Tenant-installable, trigger-driven apps + the Action Center run log; 10 trigger types; hybrid coded/recipe executor |
| 10 | **Messaging** | Channel-agnostic delivery to the handset (WhatsApp live; RCS/AMB/SMS via Infobip) + the send→await→poll→end agent loop |
| 11 | **Workflows** | The capstone — authored once, delivered to the field via Surfaces, Mobile, and Rich Messaging; the reason the other ten exist |

Cross-cutting that make every pillar work:

- **Context Engine** — bundles related entities into a single hydrated payload; declarative `[[Token]]` resolution; identity bridge (Employee / Customer / Tech rows auto-link to platform users)
- **Storage providers** — 14 backend types (Azure Blob, S3, Local, FTP, ServiceProof Cloud DAM, +); per-form storage shortcut cascade for binaries (field → section → form → catalog → tenant default)
- **EntitySync** — bi-directional auto-merging engine; SHA-1 hash dirty detection; per-mapping push/pull/both; pull-watermarks; agent registry with on-prem + cloud agents
- **WIT** — Workflow Intelligence Toolkit — embedded Ollama models for vision / OCR / text-analytics / multi-language translation; drives field-visit photo classification, signature extraction, trend hunting, anomaly detection
- **Authentication** — multi-tenant, 4-step (creds → 2FA channel pick → code → tenant select); SSO-ready; long-lived API keys with fine-grained role flags

---

## What you can do via REST — the agent's capability tour

The list below is **organized by what an agent is most likely to actually do**, not by surface alphabetical order. Each entry names the primary endpoint(s) and the relevant doc.

### Connect: bi-directional sync with merge to any data source

ServiceProofSync is the platform's near-real-time auto-merging engine. Already shipped: SQL Server, CSV, TSV, Excel, JSON files, web upload. In flight / on roadmap: ServiceTitan, generic ServiceBus, generic webhook fan-out.

- **Probe a file or stream** before deciding how to map it: `POST /api/v1/sync/wizard/probe` — server reads headers + 100 sample rows, recommends entity + property mappings, flags header rows / data type mismatches / encoding issues
- **Create a sync profile end-to-end** from one upload: `POST /api/v1/sync/profiles/from-import` — server creates Entity / Properties / Sync Profile / Field Mappings / Agent Binding in one call. The "Dream Wizard" pattern.
- **Manage sync profiles / agents / mappings**: full CRUD across 41 v1 routes under `/api/v1/sync/*`
- **Push deltas** from on-prem to platform OR **pull dirty rows** from platform to on-prem — `X-Agent-Serial` header authentication; row-hash dirty detection; pull watermark cursor; resumable
- **Mothership-mode** (one agent serving multiple SQL instances) shipped via `Tools/ServiceProofSync` foundation .NET console + Windows Service

Docs: [Sync Setup Guide](/docs/Integrators/Sync-Setup-Guide.md) · [Sync Toolkit](/docs/Integrators/Sync-Toolkit.md) — fork-and-extend production-ready foundation app

### Design: entities, properties, relationships, language

- **List + author entities**: `POST /api/v1/entities/list` · `POST /api/v1/entities` · `PUT /api/v1/entities/{id}` · `DELETE /api/v1/entities/{id}`
- **Properties** (Text / Number / Date / DateOnly / TimeOnly / Choice / Boolean / Currency / Attachment / Signature / Hierarchy / Binary): `POST /api/v1/properties` with `regEx`, `minValueOrLength`, `maxValueOrLength`, `maxDecimalPlaces`, `allowedFileTypes`, `propertyOptions[]` for Choice, `isSensitive`, `isIdentityEmail` / `isIdentityPhone` (Context Engine), `storageShortcutId` (default storage destination)
- **Composition** — entity-to-entity relationships via `EntityProperty.ChildEntityId`; cascading parent FK lookup on bulk save via `parentKey1` / `parentKey2` / `parentKey3`
- **Language fallback** — every Display column carries per-language overrides; resolution chain `requested → tenant default → InternalName`; one tenant supports N languages with one entity definition
- **Catalog import** — bulk seed entities + properties + display + options + relationships via `POST /api/v1/catalog/import` (large catalogs in one transaction)

Docs: [Entities API](/docs/Integrators/Entities-API.md)

### Load + read data — single, bulk, time-travel, variance

- **Single upsert with parent resolution**: `POST /api/v1/entities/{id}/instances/{idOrKey}` — pass `parentKey1/2/3` to silently link new children to their parent without knowing the parent's numeric id
- **Bulk upsert** for nightly sync: `POST /api/v1/entities/{id}/instances/bulk` with `importMode`: `upsert` (default; INSERT new + UPDATE changed + SKIP unchanged via SHA-1 RowHash) / `overwrite` / `insertOnly`; per-row error envelope
- **List + page**: `POST /api/v1/entities/{id}/instances/list` with `filterRules` (flat or grouped), `sort`, `pageNumber`, `pageSize`, `modifiedSinceUtc` (dirty-pull watermark)
- **As-of time-travel** on a single record: `POST /api/v1/entities/{id}/instances/{idOrKey}/as-of?utc=2025-01-15T00:00:00Z` — returns the record as it existed at that moment
- **Variance** on a single record: `POST /api/v1/entities/{id}/instances/{idOrKey}/variance` — per-property change cadence with optional `dateFrom` / `dateTo` window
- **History walk**: `POST /api/v1/entities/{id}/instances/{idOrKey}/history` — every version since the row's birth, with `who` + `when` + `what changed`
- **Deleted-since feed** for tombstone absorption: `POST /api/v1/entities/{id}/instances/deleted-since`
- **Complete-diff endpoint** (one call returns added / modified / deleted with `changeKind`): `POST /api/v1/entities/{id}/instances/changed-since`

Docs: [Entity Data API](/docs/Integrators/Entity-Data-API.md) · [Operator Cookbook](/docs/Integrators/Operator-Cookbook.md) for ready-to-run patterns

### Query: cross-entity reports with aggregation + variance + time-travel

- **Author a report definition**: `POST /api/v1/reports` with joins (parent/child + peer), filters (per-row + grouped), aggregates (SUM/COUNT/AVG/MIN/MAX), variance mode (`dateFrom` / `dateTo` / `cadence`), sort, paging
- **Execute saved report**: `POST /api/v1/reports/{id}/execute` — paged rows with `combinedPivotJson` keyed by `{Entity}_{Property}` + friendly `data` sibling for direct field reads
- **Execute ad-hoc** (no saved definition): `POST /api/v1/reports/execute` with `definitionJson` inline
- **Variance mode** — every row carries `snapshotDate` + `changeFlags` per cell; cells render with visual change indicators downstream
- **Validate before save** (CI-friendly): `POST /api/v1/reports/validate` — full `{ valid, issues[] }` envelope with paths + suggestions (Levenshtein); use in CI to catch schema drift

Docs: [Entity Reports API](/docs/Integrators/Entity-Reports-API.md) — includes the friendly-everywhere cheat sheet (which routes accept names, which take ids only)

### WIT — find trends, patterns, anomalies in your data

WIT (Workflow Intelligence Toolkit) is the platform's embedded AI layer: vision + OCR + text-analytics + translation models served by tenant-local Ollama or Azure-hosted variants. Drives:

- Field photo classification (dataplate / damage / pre-work / post-work) via WIT Vision
- Signature extraction + comparison
- Text translation (Azure Translator) — every authored string lives in MultilingualText shape; per-tenant default language + per-request override
- Sentiment + entity extraction (Azure Text Analytics) on inbound RBM / WhatsApp content
- Time-series trend hunting via the variance + as-of + reports stack — author a "monthly equipment failure rate variance" report, hand the resulting series to an agent, let it spot anomalies

WIT is reached transparently — author a property with `dataType: Attachment` + a workflow step that says "WIT.ClassifyImage(@photo)" and the model fires on save.

Docs: [WIT Vision](/docs/Integrators/../Developers/WIT-Vision.md) · [WIT Model Guide](/docs/Integrators/../Developers/WIT-Model-Guide.md)

### Forms — three audiences, one contract

- **Author a form layout** in the FormDesigner (or via REST): `POST /api/v1/entities/{id}/forms` with `LayoutJson` carrying sections (detail + list), fields, filter-as-lock, channels (web / mobile / RBM / AMB / WhatsApp), conditional visibility (`visibleWhen` FilterGroup), storage shortcut cascade per field / section / form, sensitive-property enforcement
- **Schema discovery** before authoring: `POST /api/v1/forms/{id}/schema` — full FormRecordSchema with effective storage cascade, hidden-required fields, list sections, examples
- **CRUD records**: `POST /api/v1/forms/{id}/records` (create) · `PUT /api/v1/forms/{id}/records/{idOrKey}` (update) · `DELETE` · `POST /api/v1/forms/{id}/records/list`
- **Atomic multi-section save** (hierarchical forms — Customer + Locations + Equipment in one transaction): `POST /api/v1/forms/{id}/records/multi[/{primaryIdOrKey}]` with `primary` + `sections.{name}.rows[]` + `sections.{name}.deletedEIRecordIds[]`
- **Dry-run validate** (CI-friendly): `POST /api/v1/forms/{id}/records/validate` — same rules as save, no write
- **Saved form shortcuts** for "the inbox view of this form": `POST /api/v1/forms/{id}/shortcuts` · `POST /api/v1/forms/{id}/shortcuts/{idOrName}/records/list`

The same `LayoutJson` renders on **desktop FormViewer**, **mobile PWA FormRunner** (with offline outbox + optimistic UI + binary capture + recursive drill + atomic multi-save), AND is the **write contract** integrators / agents POST against. No three-system integration to maintain.

Docs: [Forms API](/docs/Integrators/Forms-API.md) · [Form Authoring Guide](/docs/Integrators/Form-Authoring-Guide.md) · [MOBILE](/docs/Integrators/MOBILE.md)

### Storage + DAM — manage binaries across providers, signed URLs, sub-folder cascade

- **14 provider types** supported (Azure Blob / S3 / Google Drive / Local Disk / FTP / SFTP / ServiceProof Cloud DAM / etc.); per-tenant `TenantStorageSource` rows
- **Storage Shortcuts** abstract source + folder + path + sensitivity into a single ID. Per-tenant catalog with `IsShared` + `IsApiVisible` flags.
- **CRUD shortcuts via REST**: `POST /api/v1/assets/shortcuts/list` · `GET /api/v1/assets/shortcuts/{id}` · `POST /api/v1/assets/shortcuts` (create) · `PUT /api/v1/assets/shortcuts/{id}` · `DELETE /api/v1/assets/shortcuts/{id}`
- **Form-layout-driven storage cascade**: `storageShortcutId` + `storageSubFolder` (with `{PrimaryEntity}` / `{PrimaryExternalKey}` tokens) at form / section / field level. Five-level resolution narrowest-wins. **Catalog-is-bible**: sensitive properties (`Property.IsSensitive=true`) refuse non-sensitive destinations at validate + save time.
- **Upload**: `POST /api/v1/assets` (multipart) with optional `storageShortcutId` + `storageSubFolder` form fields. Returns `assetKey` referenced in form record `{ key, name }` slots.
- **Download**: `GET /api/v1/assets/{key}/download` — Bearer-auth OR SOC 2-grade signed URL (15-min user-bound HMAC, sig+exp+u query params) so `<img src>` renders without Bearer headers
- **Direct CDN URLs** when the source is non-sensitive + has `PublicUrlBase` set — fastest read path, no server round-trip
- **Sync jobs** for bidirectional cloud-storage sync: `POST /api/v1/assets/sync-jobs/list` · `GET/PUT /api/v1/assets/sync-jobs/{id}` · `POST /api/v1/assets/sync-jobs/{id}/run`

Docs: [Assets API](/docs/Integrators/Assets-API.md)

### Surfaces (Pillar 8) — declarative multi-canvas pages, MCP-friendly

Author ONE `LayoutJson` → renders identically on Portal HD desktop, mobile PWA, and (soon) RCS / AMB card carousels. **34 canonical section kinds across 5 categories** — display / embed-compose / interactive-flow / channel-aware-capture / status-feedback. Five anchor sources (currentUser / route / search / parameter / none). Four canvases.

- **CRUD**: `POST /api/v1/surfaces/list` · `POST /api/v1/surfaces/{idOrName}` · `POST /api/v1/surfaces` · `PUT /api/v1/surfaces/{idOrName}` · `DELETE /api/v1/surfaces/{idOrName}` · `POST /api/v1/surfaces/{idOrName}/validate`
- **One-shot hydrate** (LayoutJson + bundle in one call, used by `/s/{Name}` on both Portal + Mobile): `POST /api/v1/surfaces/{idOrName}/hydrate`
- **MCP / Copilot tool surface** — 9 authoring tools shipped: `list_surfaces` · `describe_surface` · `get_surface_template` · `validate_surface` · `save_surface` (validates before write; refuses on error) · `add_surface_section` · `update_surface_section` · `delete_surface_section` · `reorder_surface_section`. Plus 5 runtime navigation tools when a Copilot session is pinned to a SurfaceId.
- **9 seeded Acme demos** are the best reference catalogue — every kind in real use. See `DB.Tenant/Scripts/SeedDemoSurfaces.sql` for the full LayoutJson of each.

Docs: [Surfaces Guide](/docs/Integrators/Surfaces-Guide.md) — full kind cookbook with copy-paste JSON for the 12 highest-value kinds; all 5 anchor recipes; MCP authoring loop · [Surface Builder Guide](/docs/Integrators/Surface-Builder-Guide.md) — Portal UI authoring

### Mobile — same WASM bundle, every tenant branded

- **PWA** served same-origin under `API.WebApi` at `/mobile/*` — Blazor WebAssembly, no native build, no app-store cycle
- **Re-themable per tenant** via `Tenant.CSS` JSON (BrandName + LogoKey + FaviconKey + AppleIconKey + AndroidIconKey + CSS overrides for `--theme-*` variables)
- **Authentication** mirrors Portal's 4-step (creds → 2FA → code → tenant) with in-session tenant switch
- **Offline-first** — IndexedDB tenant-scoped + SWR cache + durable outbox + drainer-on-reconnect + optimistic UI with "Queued" badge
- **GPS + geofence** with hysteresis — arrival banner + future check-in flows
- **Menu Manager-driven** Metro tile home + drawer; tenant authors menu items flagged with `channelFlag = mobile`; appear on phones
- **Jobs hydrated from Context Engine** — `Acme_TechWorklist` bundle pattern; pre-enriched parent + child entity rows in one round-trip via Wave 10.2 batched fetch
- **Forms render every authored form** with full Phase 3.4 binary contract (camera + library + Web Share + 25MB cap + offline outbox), conditional visibility, dropdown / combo (4 source types), hierarchical drill with recursive child editing, atomic multi-save, per-row error chrome, client-side validation mirror
- **Views + Reports renderers**: `/views/{Name}` + `/reports/{Name}` real renderers via shared `TabularResponseParser`; Cards / Table mode toggle
- **Surfaces** render via universal `SurfaceRunner` — every Pillar 8 kind ships on mobile (8 providers registered)
- **SOC 2-grade signed asset URLs** — `<img src>` works without Bearer; per-tenant HMAC; 15-min user-bound

Docs: [MOBILE.md](/docs/Integrators/MOBILE.md)

### Tenants, users, branding, email templates, API keys

Global-admin-scoped Tenant Admin v1 — provision a brand-new white-labeled tenant end-to-end via REST:

- **Provision a tenant**: `POST /api/v1/tenants` — name + sub-domain + host + description + initial admin user + tenant CSS JSON in one call
- **Manage tenants**: `POST /api/v1/tenants/list` · `GET /api/v1/tenants/{id}` · `PUT /api/v1/tenants/{id}` · `POST /api/v1/tenants/{id}/suspend` · `POST /api/v1/tenants/{id}/activate`
- **Branding via REST** (no Portal UI required): `GET /api/v1/tenants/{id}/branding` · `PUT /api/v1/tenants/{id}/branding/css` · `POST /api/v1/tenants/{id}/branding/images` (base64 OR URL; server auto-processes into Logo + Favicon32 + Favicon180 + Favicon192)
- **Languages**: `POST /api/v1/tenants/{id}/languages/list` · `POST /api/v1/tenants/{id}/languages` (enable / disable / set default)
- **Email templates**: `POST /api/v1/tenants/{id}/email-templates/list` · `POST /api/v1/tenants/{id}/email-templates/clone` · `PUT /api/v1/tenants/{id}/email-templates/{templateType}` (per-locale insert OR update) · `POST /api/v1/tenants/{id}/send-email`
- **Users**: 8 routes for full lifecycle including `find-or-create` with auto-provisioning (idempotent integration); roles via `POST /api/v1/tenants/{id}/users/{id}/roles`
- **API Keys**: long-lived bearer tokens with fine-grained role flags (BuilderAdmin / DataView / DataImport / FileEdit / AdminUser / AdminIntegration / AdminCSS / etc.) — narrow each integration to the smallest role set it needs

Docs: [Tenant Admin API](/docs/Integrators/TenantAdmin-API.md) · [Users API](/docs/Integrators/Users-API.md) · [Authentication](/docs/Integrators/Authentication.md)

### Context Engine + Identity Bridge — the multilingual `[[ ]]` resolver

The platform's central meaning layer. A workflow step that says `[[Customer.OrgName]]` resolves by walking the hydrated bundle for the anchored Customer row + reading its `OrgName` property. Same resolver drives email tokens, RBM message templates, form labels, surface section titles.

- **Identity Bridge** — mark an entity `IsTenantUserRole=true` AND its email / phone property `IsIdentityEmail=true` / `IsIdentityPhone=true`. The platform auto-links sync-ingested rows to platform users; auto-invites on first appearance (configurable per sync profile via `AutoInviteOnSync`). Idempotent + re-runs to catch up.
- **Context Definitions** are tenant-authored bundles — pick anchor entity + its parent / child / lookup / view / report slots. Hydrate via `POST /api/v1/context/{name}/hydrate` with an anchor identity. Mobile Jobs page consumes the `Acme_TechWorklist` bundle this way.

Docs: [Context Engine Guide](/docs/Integrators/Context-Engine-Guide.md) — operator-facing setup + multi-flag scenarios + MERGE semantic guarantees + SOC 2 audit story

### Future — RBM / AMB / WhatsApp / SMS workflows (the centerpiece)

The whole "field-side workflow" story is in flight: declarative workflow definitions + step types (collect / branch / display / capture / approve / wait / fan-out) + channel-aware rendering (RBM rich cards / AMB messages / WhatsApp text + media / SMS fallback / mobile-web fallback) + the workflow runner state machine. Workflow CRUD via REST is already shipped (13 endpoints under `/api/v1/workflows/*`); the channel-rendering layer is the next sprint.

When live: workflows fire when an entity changes (or on a schedule, or on a webhook); the message goes out via the customer's preferred channel; their tap or reply lands as an inbound workflow event; the entity gets enriched with the resulting data; the loop closes.

Docs: [Workflows API](/docs/Integrators/Workflows-API.md) — CRUD shipped; channel-rendering doc lands when that surface ships

---

## Data + structured endpoints (most LLM-friendly)

- **[/api/postman.json](/api/postman.json)** — full Postman v2.1 collection. ~370 requests across 27+ folders. Every public v1 endpoint with descriptions, headers, body samples, `{{baseUrl}}` + `{{apiKey}}` substitution. **The fastest way to learn the wire format** is to import this into Postman.
- **[/api/response-shapes.json](/api/response-shapes.json)** — per-endpoint response field tables + input field tables + return codes + the source stored-procedure mapping. Generated by walking the controllers + DMOs + .sql files. The fastest way for an LLM to answer "what does this endpoint return?" without firing it.
- **[/api/enrichments.json](/api/enrichments.json)** — per-endpoint long-form context + cross-referenced documentation links.
- **[/llms-full.txt](/llms-full.txt)** — concatenated plain-text version of every public Integrator doc. Refreshed at request time from the canonical `docs/public/Integrators/*.md` set.
- **[/sitemap.xml](/sitemap.xml)** — all public + integrator-accessible URLs.

---

## Doctrine an agent should respect

Three rules that prevent the most common integration mistakes:

1. **Validate before you save.** Every authoring surface (Reports / Views / Forms / Surfaces) has a `/validate` endpoint that returns the same `{ valid, issues[] }` envelope as the real save. Issues carry JSON-path + severity (`error` blocks save, `warning` accepted-but-flagged) + Levenshtein-suggested fix. Run validate in CI to catch schema drift before production jobs break.
2. **Friendly OR canonical, never both.** Every `{idOrName}` route slot accepts numeric ID OR friendly InternalName. Every save payload accepts property InternalNames OR EntityPropertyIds. Pick one style per integration; the server fills the gap. Mixing styles is fine but creates wire noise.
3. **camelCase on the wire, always.** Every JSON field is camelCase. OPENJSON paths in stored procs are case-sensitive — `eiRecordId` works, `EIRecordId` does not. Use a serializer with `PropertyNamingPolicy = JsonNamingPolicy.CamelCase` and you're safe.

---

## Auth flow for AI agents — three options

**Option 1 — HTTP Basic Auth** (stateless, simplest):
```
curl -u integrator:ServiceProof!nt3gr8! https://developer.serviceproof.net/llms-full.txt
```

**Option 2 — JSON login → bearer token** (15-min sliding, refresh-friendly):
```
POST /api/auth/login
Content-Type: application/json

{"username":"integrator","password":"ServiceProof!nt3gr8!"}

# Returns: {"token":"...", "expiresInSeconds":900, "role":"integrator", ...}
# Subsequent calls: Authorization: Bearer <token>
```

**Option 3 — Cookie auth** (the human/browser path):
```
POST /login
Content-Type: application/x-www-form-urlencoded

username=integrator&password=ServiceProof!nt3gr8!
```
Capture `Set-Cookie: DevPortal.Auth=...`, send it on subsequent requests.

All three options accept the same credentials and honor the same role gates. See [/ai-agents](/ai-agents) for the full reference.

---

## What to read next

If you're new to the platform: start with [`/llms-full.txt`](/llms-full.txt) — that's every public Integrator doc concatenated. Then load the [Postman collection](/api/postman.json) for runnable wire samples.

If you have a specific job to do, go to the matching doc above (Connect / Design / Load / Query / WIT / Forms / Storage / Surfaces / Mobile / Tenants / Context Engine). Each one stands alone — you shouldn't need to bounce between them to do one thing.