For the complete documentation index, see llms.txt. This page is also available as Markdown.

Building with LLMs

How agents and builders use machine-readable docs, OpenAPI, and safer integration patterns.

impact.com teams increasingly pair agents, assistants, and retrieval systems with the impact.com APIs. Those systems work best when they can anchor on truthful, structured context: a small discovery file (llms.txt), selectively fetched pages (*.md), consolidated text (llms-full.txt) when embedding the whole corpus, and OpenAPI for concrete operations—not on memory or guesswork.

Machine-readable documentation

llms.txt (always start here)

llms.txt is a concise, Markdown-formatted index of published documentation. Agents and tooling should GET it early in a session—or cache it for a defined TTL—to discover linked guides and references before issuing API calls.

Canonical URL: https://integrations.impact.com/llms.txt

What it provides

  • A browseable outline of the Integrations Hub: getting started, authentication, developer tools, AI solutions, integration guides, API reference entry points, and related material.

  • Direct URLs to each page’s Markdown source, typically URLs ending in .md on integrations.impact.com.

Suggested agent flow

  1. Fetch https://integrations.impact.com/llms.txt.

  2. Parse outbound links matching your task (for example Authenticate, a specific REST tag, or a tracking guide).

  3. GET only those .md pages plus the smallest useful OpenAPI slice (see OpenAPI specifications).

That keeps context fresh, scoped, and within token budgets.

llms-full.txt (full hub text)

llms-full.txt is a single concatenated export of the Integrations Hub content: one plaintext/Markdown document suitable for bulk ingestion rather than incremental browsing.

Canonical URL: https://integrations.impact.com/llms-full.txt

When to use it

  • Offline or snapshot ingestion (archives, mirrored copies).

  • Embedding search (“index the whole book once”) across narrative guides.

  • Wide onboarding flows where fetching hundreds of URLs is inconvenient.

Caveats

  • The artifact is large; runtime agents should normally prefer llms.txt + selective .md fetches.

  • The export may retain portal markup artifacts (for example templating snippets or embedded HTML alongside Markdown). Sanitize or chunk accordingly for your retrieval pipeline.

Per-page Markdown

Every meaningful page has a GET-able Markdown representation. The authoritative list of URLs is llms.txt; developers should not hand-maintain parallel URL lists.

Recommended practice

  • For each workflow, load Authenticate, Errors, rate-limit or versioning docs, plus only the endpoints and guides you intend to automate.

  • Refresh from llms.txt when deployments change slug structure or TOC order.

OpenAPI specifications

OpenAPI (e.g. 3.x) describes operations, schemas, authentication, examples, and error shapes in machine-parseable form. Use it for tool definitions, codegen, and validating model-generated payloads against real field names and types.

Where to obtain specs

  • OpenAPI documents are exposed from API reference surfaces in this portal (YAML/JSON downloads or viewer exports, depending on publication settings). Prefer the canonical link surfaced in-product for Brand, Partner, and Agency APIs over guessed paths.

How to combine with prose

Source
Typical use

OpenAPI

Parameter types, enums, HTTP methods/paths, security schemes, canonical request/response models.

Markdown guides

Sequencing, edge cases, product behavior not fully expressed in the schema, deprecation notices.

llms.txt / selective .md

Narratives; keep token load small during live reasoning.

For LLM-heavy flows, split large specs: include only paths and components referenced by active tools rather than dumping an entire mega-spec into prompt context.

Copying documentation as Markdown

Technical writers and engineers often paste doc fragments into chats, prompts, runbooks, or tickets. Humans should:

  1. Open the desired page at integrations.impact.com in the browser.

    • To the right of the page title, selectMore and select Copy page.

  2. Use the portal Copy, Markdown, or equivalent, or copy directly from the .md URL referenced in llms.txt when stable links are preferable.

  3. Redact Account SID/Auth Token, OAuth tokens, bearer tokens, and customer identifiers from examples before pasting into third-party assistants.

  4. Prefer narrow excerpts (for example Authentication or a single endpoint chapter) rather than dumping whole hierarchies unless you are building an offline bundle.

Agents should GET .md or OpenAPI programmatically rather than scraping from the rendered HTML DOM.

Designing reliable LLM-powered integrations

  1. Treat model output as untrusted input. Validate JSON against OpenAPI-derived schemas before calling production APIs. Reject malformed types, unexpected enums, and out-of-range values. Never forward raw completions as HTTP bodies unchecked.

  2. Prefer tools (function calling) over prose-only prompts. Narrow tools that wrap individual operations reduce hallucinated URLs/verbs. Add llms.txt-linked Markdown where behavior exceeds the schema.

  3. Budget context aggressively. Start from llms.txt, then GET only pertinent .md pages and trimmed OpenAPI. Reserve llms-full.txt for offline/index-time use unless you deliberately need breadth. Retrieval-on-demand (RAG/MCP backends) usually beats mega-pastes.

  4. Honor authentication distinctions. Own-account integrations use HTTP Basic with Account SID and Auth Token unless a path specifies otherwise. Multi-customer apps follow OAuth 2.0 Authorization Code + PKCE and documented token rotation, as described in Authenticate.

  5. Plan for bursts and backoff. Automated agents retry aggressively; implement 429 handling, jittered backoff, concurrency caps, and idempotency patterns where replay is safe.

  6. Operational traceability. Log tool names, sanitized arguments, latency, outcome codes, and correlation identifiers when available.

Ask this documentation programmatically

All page on integrations.impact.com support an ask query parameter. Supply a specific natural-language question to receive a concise answer plus documentation excerpts. Response shape follows the portal implementation.

Pattern

Last updated