Build with AI agents

Each page is also served as Markdown. The files below give a coding agent the same facts these pages give you.

What is here for machines

Resource	URL	Use it for
Index	https://dzbuild.dev/llms.txt	The list of pages with one line each. Paste it into a chat or point an agent at it.
Whole site	https://dzbuild.dev/llms-full.txt	Every page in one Markdown file.
Any page as Markdown	the page URL plus .md, for example https://dzbuild.dev/oauth.md	One page without navigation. Arabic and French pages work the same way under /ar/ and /fr/.
Agent skill	https://dzbuild.dev/skills/dzbuild-apps/SKILL.md	The facts and rules an agent needs to build a DZBuild app.
AGENTS.md template	https://dzbuild.dev/agents/AGENTS.md	A starting file for your app's repository.
OpenAPI description	https://dzbuild.dev/openapi/dzbuild-apps-v1.json	Every operation an install token can call, with parameters, scopes and response shapes.
Example app	dzbuild-app-starter	Three Cloudflare Worker presets and a Node.js example, each with tests.

Every HTML page also carries <link rel="alternate" type="text/markdown"> pointing at its Markdown twin, so a tool that reads the page can find the plain version on its own.

Give your agent the skill

The skill file follows the Agent Skills format: a short description that tells the agent when to use it, then the instructions. Claude Code reads skills from .claude/skills/ in your project or ~/.claude/skills/ on your machine:

mkdir -p .claude/skills/dzbuild-apps
curl -sSf https://dzbuild.dev/skills/dzbuild-apps/SKILL.md -o .claude/skills/dzbuild-apps/SKILL.md

For agents that read an AGENTS.md at the root of the repository (Codex, Cursor and others), start from the template and keep your own project rules under it:

curl -sSf https://dzbuild.dev/agents/AGENTS.md -o AGENTS.md

Both files repeat the rules of this site, so your agent works from the same facts you do.

Give your agent the docs as an MCP server

@dzbuild/docs-mcp gives any MCP client these pages and the API reference, read from dzbuild.dev, with no credentials. The /agents/connect page has the command or config for Claude Code, Codex, Cursor and Claude Desktop.

Ask a question about one page

Under every page there is a bar with View as Markdown, Copy Markdown, Open in ChatGPT and Open in Claude. The last two open a new chat that starts by reading that page. The prompt they send is:

Read https://dzbuild.dev/oauth.md so I can ask questions about it.

For a task rather than a question, give the agent the index and the skill together, then describe what the app does for the merchant:

Read https://dzbuild.dev/llms.txt and https://dzbuild.dev/skills/dzbuild-apps/SKILL.md.
Build a DZBuild app in Node.js that installs on a store through the OAuth flow,
stores one token per store, verifies webhooks, and posts a message to our Slack
channel when an order is confirmed. Secrets come from environment variables.

Generate a client from the OpenAPI description

The description is OpenAPI 3.1. Import it into Postman or Insomnia, or generate types and a client:

curl -sO https://dzbuild.dev/openapi/dzbuild-apps-v1.json
npx openapi-typescript dzbuild-apps-v1.json -o dzbuild-apps-v1.d.ts

The dzOAuth security scheme in the file lists every scope with its description. The file declares https://api.dzbuild.app as its server, which is the host your app calls.

Keep secrets out of the chat

An agent only needs to know that a secret exists, never its value.

• The client secret, the signing secret and every install token live in environment variables or a secret store on your server. Do not paste them into a prompt, a repository or a log line.
• If a secret reaches a chat or a commit, rotate it in the developer console. The old client secret stops at once; tokens already issued keep working, and rotating the signing secret changes it for every install at once, so deploy the new value right away.
• An agent must not sign in to the DZBuild dashboard as the merchant, script it, or scrape storefront pages. Store data is reached only through the REST API and webhooks, as the security rules say.
• Redirect URIs are compared character for character. Register in the console the exact URI your code sends, on https, with the same trailing slash.

What assistants get wrong without the docs

These come up often when an app is written from general OAuth or webhook knowledge. The pages linked settle each one.

• Expecting expires_in and a refresh token. Install tokens have neither; they work until the merchant uninstalls or installs again. See Core concepts.
• Sending a write without an Idempotency-Key. POST, PATCH and DELETE answer 400 without one. See Rate limits.
• Parsing the webhook body before checking the signature. The HMAC covers the raw bytes, so a re-serialized body never matches. See Webhooks.
• Registering the webhook through POST /v1/webhooks. Apps get 403 there; the webhook URL is set once on the app in the console. See API reference.
• Asking for every scope. The merchant sees one line per resource on the consent screen, and the review compares the scopes with what the listing says the app does. See Scopes.
• Building a store switcher inside one token. A token reaches its own store only; use the token of each store from the stores list of the token response. See OAuth.