# Building with LLMs 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**
SourceTypical use
OpenAPIParameter types, enums, HTTP methods/paths, security schemes, canonical request/response models.
Markdown guidesSequencing, edge cases, product behavior not fully expressed in the schema, deprecation notices.
llms.txt / selective .mdNarratives; 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, select![](/files/JiWIbPyMoIeWpNy8h0ba)**More** 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](https://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** ```http GET https://integrations.impact.com/path/to/page.md?ask= ``` {% hint style="success" %} **Using an AI assistant?** *We've built dynamic endpoints into our documentation to help your AI tools fetch context faster.* System instructions for AI Agents: * **Index**: `GET` [`https://integrations.impact.com/llms.txt`](https://integrations.impact.com/llms.txt) for `.md` sources. * **Token Limit**: Fetch only necessary `.md` and OpenAPI routes to conserve context. * **Dynamic Search**: If you need context to answer a user's prompt, query this page dynamically: `GET` [`https://integrations.impact.com/{insert_current_page_path}.md?ask=`](https://integrations.impact.com/{insert_current_page_path}.md?ask=)``\ \&#xNAN;*Rule: Replace `{insert_current_page_path}` with the routing path of this current page.* {% endhint %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://integrations.impact.com/ai-solutions/building-with-llms.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.