Building with an AI assistant

Most new integrations now get their first draft written by an AI coding assistant — Claude Code, Cursor, Copilot, or similar — with an engineer reviewing and steering. This page is what to hand it: the OpenAPI spec, the guides, and one index file per product built for exactly that handoff.

Start with Getting Started's own index: authentication, environments, webhooks, and testing are shared across every product, so paste that in before you paste in a specific product's files. Then grab the product you're integrating.

Product	Start here	API Reference	Feed your assistant
eClose	Create a hybrid closing	Specs	llms.txt · llms-full.txt
Notary Connect	Getting started	Specs	llms.txt · llms-full.txt
Quality Control	Getting started	Specs	llms.txt · llms-full.txt
eVault	Integrating to Snapdocs eVault	Specs	llms.txt · llms-full.txt

llms.txt is a plain-text index of links, ordered the same way the guide nav is — read it if your tool can fetch URLs on its own. llms-full.txt inlines the guide text itself, for pasting straight into a chat window. Every OpenAPI spec is also downloadable directly from its API Reference page, next to its title. The whole site has one combined index too, at /llms.txt.

A prompt to start from

I'm integrating with the Snapdocs {product} API in {language}.

Context:
- OpenAPI spec: {spec download URL from the API Reference page}
- Guide index: {that product's llms-full.txt URL}

Build a client that:
1. Authenticates with OAuth2 client_credentials and caches the access token
   for its stated lifetime, instead of fetching a new one per request.
2. Calls {the operations for your workflow, in order}.
3. Verifies webhook signatures before trusting a payload.
4. Handles errors using the status codes and error bodies in the spec.

Run it against the staging environment first, not production.

Fill in the product, language, and workflow; the shape holds for every product on this page.

What it gets wrong if you skip the guides

An assistant working from the OpenAPI spec alone writes code that compiles and looks right, and still gets a few things wrong every time: it re-fetches a bearer token on every call instead of caching it, it retries a failed POST without checking whether that write is safe to repeat, and it trusts a webhook payload before checking the signature. None of this shows up in the spec — it's only in the guides. Snapdocs doesn't promise every write is safe to retry blindly; treat POST operations as non-idempotent unless an operation's own description says otherwise, and let your client dedupe rather than assume the API will.

The spec is regenerated on every deploy. If a work session runs long, re-download it rather than trusting whatever your assistant cached at the start.

Next steps

Environments covers which host to point your first request at.