> ## Documentation Index
> Fetch the complete documentation index at: https://developer.fieldnode.com/llms.txt
> Use this file to discover all available pages before exploring further.

# AI Coding

You can build against the Fieldnode API with an AI coding assistant — Claude, ChatGPT, Cursor, Copilot, or any tool that accepts external context. This guide covers the inputs that make the assistant's output reliable instead of hallucinated.

## Give the assistant the OpenAPI spec

The single most useful input is the spec itself. It contains every endpoint, parameter, response model, and error code — fully typed.

* Download: [openapi.json](/api/openapi.json)
* Paste it (or attach it) into your chat. For long sessions, point the assistant at the URL and ask it to refer back to it.

A good first prompt:

> Here is the Fieldnode OpenAPI spec: `<paste or URL>`. Authentication is `Authorization: Bearer pat_…`. Base URL is `https://api.lab.fieldnode.dev`. Use only endpoints and fields that appear in this spec.

The "only endpoints and fields that appear in this spec" line meaningfully reduces hallucinated routes and parameters.

## Use the page-level "Open in…" actions

Every page in these docs has an action menu (top-right) with shortcuts for popular AI tools:

* **Copy as Markdown** — paste the current page into any chat.
* **Open in ChatGPT / Claude / Perplexity** — opens a new conversation prefilled with the page contents.
* **Open in Cursor / VS Code** — drops the page into your editor's AI context.
* **MCP** — copies the MCP connector snippet for tools that support it.

When you are stuck on a specific endpoint or guide, this is faster than copy-pasting URLs.

## Feed the assistant the whole docs site

Mintlify publishes machine-readable indexes of this site:

* `/llms.txt` — short index of every page.
* `/llms-full.txt` — concatenated full contents of every page in one file.

Attach `llms-full.txt` when you want the assistant to answer general questions across multiple guides without you having to find the right page first.

## Generate a typed client, then prompt against it

For real code, do **not** ask the assistant to hand-write `fetch` calls — generate a typed client from the OpenAPI spec first and let the assistant call it. Examples:

* TypeScript: [openapi-typescript](https://github.com/openapi-ts/openapi-typescript) or [@hey-api/openapi-ts](https://heyapi.dev/).
* Go: [oapi-codegen](https://github.com/oapi-codegen/oapi-codegen).
* Java / Python / C# / Ruby / …: [openapi-generator](https://openapi-generator.tech/).

Then prompt:

> Using the generated client in `./src/fieldnode-client`, write a function that creates a part, uploads `drawing.pdf` via `POST /v1/uploads`, and attaches it under group `document` with `PATCH /v1/parts/{id}/files`.

The assistant works against your real types — wrong endpoints and bad field names fail at compile/lint time, not at runtime.

## Effective prompts

A few patterns that work well in practice:

* **Specify the environment.** Lab, Sandbox, or Production — the URLs differ, and the assistant will guess if you don't say.
* **Quote the relevant guide.** Paste the [Upload guide](./upload) into the chat when you ask for upload code; the assistant will follow the three-step flow instead of inventing one.
* **Ask for the error envelope.** Tell the assistant to handle the [error JSON shape](../errors) (`code`, `status`, `message`, `data`) — it produces better error handling than a generic `try/catch`.
* **Request a `curl` first, then code.** A working `curl` is easier to verify against the spec than a 40-line client. Once it works, ask the assistant to translate.

## What AI assistants tend to get wrong

Verify these even when the rest of the code looks right:

* **Snake\_case vs camelCase.** Fieldnode request and response fields are `camelCase` — assistants sometimes default to `snake_case`.
* **Batch-get URLs.** Collection lookups use a `:batch-get` action on the resource (e.g. `POST /v1/orgs:batch-get`), not query-string ids. Assistants frequently invent `?ids=…`.
* **File group names.** The valid groups are `preview`, `document`, `ip`, `partDevelopment`, `development` — see the [Upload guide](./upload).
* **Error codes.** Codes are `SCREAMING_SNAKE_CASE` (`NOT_FOUND`, not `not_found`).
* **`uploadId` vs file `id`.** Attaching uses the **upload** id (from `POST /v1/uploads`); removing uses the **file** id (from `GET /v1/parts/{id}/files`).