Skip to main content
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
  • 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: 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 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 (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.
  • 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).