Start with one endpoint, not your entire API. The goal is a reference page that explains the public contract, traces its claims to implementation evidence, and leaves unresolved questions visible. Follow this walkthrough to produce a reviewable draft without asking the model to invent missing behavior.
1. Prepare a Documentation-Only Working Branch
Create a branch and choose one public endpoint. Identify its route registration, handler, request validator, response serializer, authentication middleware, and relevant tests. Give Claude Code those paths explicitly: it can read repository files, edit documents, and run commands. ([code.claude.com](https://code.claude.com/docs/en/overview))
Before sharing repository content, check your organization's rules for external model processing. Exclude secrets, production records, and sensitive fixtures. Review Claude Code's permission settings before approving commands or file changes; permissions provide controls beyond instructions in a prompt. ([code.claude.com](https://code.claude.com/docs/en/permissions))
2. Record the API Reference Rules in CLAUDE.md
Use the project's CLAUDE.md file for repeatable documentation instructions. Claude Code supports these files as persistent project guidance, making them a suitable place for your reference-page conventions. ([code.claude.com](https://code.claude.com/docs/en/memory))
Add a short policy: document public behavior only, preserve existing terminology, distinguish missing values from null values, and never infer defaults or guarantees. Specify the output directory and instruct Claude to leave application code unchanged. Treat that instruction as task scope, not a security boundary.
Suggested instruction: Every behavioral claim must have a source location in a separate review note. Mark unsupported details as unresolved instead of filling them with plausible text.
3. Request an Endpoint Evidence Map Before Prose
Ask Claude Code to inspect the selected files before drafting. Its repository-reading capability supports this evidence-gathering stage; keep the requested search bounded to the endpoint and its dependencies. ([code.claude.com](https://code.claude.com/docs/en/overview))
Suggested prompt: Inspect this endpoint's registration, middleware, validation, handler, serializer, and tests. Return the public method and path, accepted inputs, emitted responses, and supporting file locations. Do not write documentation yet. List contradictions and missing evidence separately.
Review the map yourself. If implementation and tests disagree, flag the discrepancy for an owner rather than silently choosing whichever version produces cleaner prose.
4. Draft One Page Against a Fixed Template
Once the evidence map is approved, ask Claude Code to create the page in your existing documentation format. File editing is a supported capability, so request an actual draft file rather than only a conversational answer. ([code.claude.com](https://code.claude.com/docs/en/overview))
- Endpoint: Method, public path, purpose, and authentication requirements.
- Request: Path, query, header, and body fields with types and constraints.
- Response: Status codes, response fields, and omission rules.
- Errors: Verified conditions, response shapes, and actionable explanations.
- Examples: Synthetic requests and matching responses.
Keep internal database names and implementation details out unless they are part of the public contract. Ask for a separate uncertainty list so the published page does not accidentally present assumptions as promises.
5. Validate API Examples Against Local Behavior
Request examples using synthetic identifiers and placeholder credentials. Require every response field and status code to match the evidence map. Do not add pagination, idempotency, rate limits, or retry guarantees merely because similar APIs have them.
Run approved examples against a local test environment or existing integration harness, never production by default. Check authentication failures, invalid input, and optional-field behavior alongside the successful request. Record which examples actually ran; label unexecuted examples for reviewer verification.
6. Configure SwiftRelay for the Drafting Session
If you want pay-as-you-go access for this workflow, SwiftRelay works with Claude Code and bills per token. Use its Claude Code configuration with the bare API host, without adding the /v1 suffix used by OpenAI-compatible SDKs. Keep credentials outside tracked repository files.
Sign up for SwiftRelay to try the workflow with the small gift credit provided to new accounts. Keep the same evidence requirements regardless of which supported model you select.
7. Review the Documentation Diff Before Publishing
Ask Claude Code to compare the draft against the evidence map and report unsupported claims. Then inspect the diff yourself, run your documentation build, and confirm that only intended files changed.
Have an endpoint owner approve authentication, defaults, error behavior, and compatibility language. Merge the page with its relevant tests or source change, and repeat the process for the next endpoint. The deliverable is a verified public contract, not simply polished prose.